Data center management via out-of-band, low-pin count, external access to local motherboard monitoring and control

ABSTRACT

Provided is an external secondary computing device configured to monitor or control a rack-mounted computing device independently of whether the rack-mounted computing device is operating or is turned off via a low-pin-count motherboard bus independently of a baseboard management controller.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation-in-part of U.S. patentapplication Ser. No. 15/366,528, titled DATA CENTER MANAGEMENT, filed 1Dec. 2016, which is a continuation-in-part of U.S. patent applicationSer. No. 15/065,212, titled OUT-OF-BAND DATA CENTER MANAGEMENT VIA POWERBUS, filed 9 Mar. 2016, which claims the benefit of the following U.S.Provisional patent applications: U.S. 62/130,018, titled RACK FORCOMPUTING EQUIPMENT, filed 9 Mar. 2015; U.S. 62/248,788, titled RACK FORCOMPUTING EQUIPMENT, filed 30 Oct. 2015; and U.S. 62/275,909, titledRACK FOR COMPUTING EQUIPMENT, filed 7 Jan. 2016. The entire content ofeach parent application is incorporated by reference in its entirety.

BACKGROUND

1. Field

The present invention relates generally to computing equipment and, morespecifically, to secondary computing devices to monitor and controlprimary computing devices for data centers.

2. Description of the Related Art

Data centers are often used to house and interconnect large collectionsof computing devices, like servers, databases, load balancers, andhigh-performance computing clusters. Often, the computing devices areinterconnected with two different networks: 1) an in-band network forconveying the data upon which the computing devices operate, forexample, content in webpages, queries and query responses, and data forhigh-performance computing; and 2) an out-of-band management network forconveying commands to the individual computing devices to manage theiroperation, e.g., for conveying information like sensor data indicativeof the operation of the computing devices or for remote serial consolesessions for server management.

Out-of-band management serves a number of purposes, depending on thecontext. Often, out-of-band management networks are used to managesecurity risk, by limiting the attack surface of a network that could beused to control the computing devices and segregating the in-bandnetwork that often receives data from the outside world. In some cases,out-of-band management networks are operative to remotely control thecomputing devices even when the computing devices are turned off, forexample, by accessing memory on computing devices that is persistent(like flash memory) to perform things like extensible firmware interface(e.g., BIOS or UEFI) updates, read values from registers indicative ofconfiguration or state, and the like. Other examples of activitiesinclude booting a device that is been turned off, remote installation ofoperating systems, updates, setting hardware clock speeds, updating orquerying firmware versions, and the like.

Out-of-band management is often implemented with computing hardware thatis independent of the operating system of the managed (e.g., monitoredor controlled) host (i.e., primary) computing device. For instance, theIntelligent Platform Management Interface (IPMI) family ofspecifications provide for a baseboard management controller (BMC) thatsupports remote management of a host computing device. The BMC isusually a distinct computer, with its own processor, memory, operatingsystem, and network interface, relative to that of the host computer.Often, the BMC on-board the motherboard of the host system and connectsto the various components thereon, providing relatively extensive accessto the host system for management thereof.

Traditional BMC implementations present a number of issues. Often, theydramatically expand the attack surface of a computer system, providing aseparate operating system that, once compromised, continues to operateoutside of the host system's operating system in a privileged state. Inmany cases, BMC passwords are not secured, are difficult to manage, andare shared by a relatively large number of computing devices in a datacenter. Further, once compromised, an on-board BMC can be difficult toremove, e.g., in some cases requiring a chip be desoldered or that thehost system be discarded. Further, BMCs with dedicated on-board networkinterfaces further expand the set of components on a motherboard that anattacker may attempt to compromise.

Other techniques for remotely managing a computing device often operatethrough a UEFI or operating system of the host device, which presentsother issues. For instance, it can be difficult to troubleshoot a deviceremotely when the device crashes, as the operating system or UEFI isoften non-responsive at that point. Further, it can be difficult toreconfigure devices while the operating system or UEFI is not running.(The discussion of these issues should not be taken as a disclaimer ofany subject matter, as the present techniques may also be used inconjunction with older approaches).

SUMMARY

The following is a non-exhaustive listing of some aspects of the presenttechniques. These and other aspects are described in the followingdisclosure.

Some aspects include a secondary computing device configured to monitoror control a rack-mounted computing device independently of whether therack-mounted computing device is operating or is turned off, thesecondary computing device comprising: a low-bandwidth bus connectorconfigured to connect to low-bandwidth bus on a motherboard of arack-mounted computing device; and an off-motherboard microcontrollerelectrically coupled to the low-bandwidth bus connector, themicrocontroller comprising one or more processors and memory storinginstructions that, when executed by at least some of the processors,effectuate operations comprising: receiving, with an off-motherboardnetwork interface, via an out-of-band network, a first command fromcomputing device configured to monitor or control a plurality ofrack-mounted computing devices; sending a second command based on thefirst command via the connector to an electronic device coupled to thelow-bandwidth bus on the motherboard; receiving a response to the secondcommand via the low-bandwidth bus from the electronic device; andtransmitting data based on the response, with the off-motherboardnetwork interface, via the out-of-band network, to the computing deviceconfigured to monitor or control a plurality of rack-mounted computingdevices.

Some aspects include a tangible, non-transitory, machine-readable mediumstoring instructions that when executed by one or more processorseffectuate the above operations.

Some aspects include a process including the above operations.

BRIEF DESCRIPTION OF THE DRAWINGS

The above-mentioned aspects and other aspects of the present techniqueswill be better understood when the present application is read in viewof the following figures in which like numbers indicate similar oridentical elements:

FIG. 1 is a physical-architecture block diagram that illustrates a datacenter configured for out-of-band management via power bus, inaccordance with some embodiments;

FIG. 2 is a physical-architecture block diagram that illustrates a datacenter configured for out-of-band management without using a power busfor communication, in accordance with some embodiments;

FIG. 3 is a physical-and-logical-architecture block diagram thatillustrates a data center configured for out-of-band management withoutusing a power bus for communication and with a rack controller executedby a managed device, in accordance with some embodiments;

FIG. 4 is a physical-and-logical-architecture block diagram thatillustrates a data center configured for out-of-band management via apower bus and with a rack controller executed by a managed device, inaccordance with some embodiments;

FIG. 5 is a flow chart that illustrates an example of a process forout-of-band management of a data center, in accordance with someembodiments;

FIG. 6 is a flow chart that illustrates an example of a process tomanage rack-mounted computing devices, in accordance with someembodiments;

FIG. 7 is a block diagram of a topology of a data center managementsystem, in accordance with some embodiments;

FIG. 8 is a flow chart that illustrates an example of a process executedby the system of FIG. 7 to manage a data center, in accordance with someembodiments;

FIG. 9 is an example of a secondary computing device configured tomonitor and control a primary computing device in accordance with someembodiments;

FIG. 10 is a flow chart that illustrates a process to monitor andcontrol a primary computing device in accordance with some embodiments;and

FIG. 11 is a diagram that illustrates an exemplary computing system bywhich the above processes and systems may be implemented, in accordancewith embodiments of the present techniques.

While the invention is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and will herein be described in detail. Thedrawings may not be to scale. It should be understood, however, that thedrawings and detailed description thereto are not intended to limit theinvention to the particular form disclosed, but to the contrary, theintention is to cover all modifications, equivalents, and alternativesfalling within the spirit and scope of the present invention as definedby the appended claims.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

To mitigate the problems described herein, the inventors had to bothinvent solutions and, in some cases just as importantly, recognizeproblems overlooked (or not yet foreseen) by others in the field of datacenter equipment design. Indeed, the inventors wish to emphasize thedifficulty of recognizing those problems that are nascent and willbecome much more apparent in the future should trends in the data centerindustry continue as applicants expect. Further, because multipleproblems are addressed, it should be understood that some embodimentsare problem-specific, and not all embodiments address every problem withtraditional systems described herein or provide every benefit describedherein. That said, improvements that solve various permutations of theseproblems are described below.

This patent disclosure describes several groups of inventions that canbe, but need not necessarily be, used together. The groups are describedin a sequence that generally follows their relative proximity to theedge of an out-of-band network or networks. A first group of inventionsdescribed with reference to FIGS. 1-4 and FIG. 5 relates to a system andprocess by which an out-of-band network may be implemented between arack-mounted computing device and rack controllers or other data centermanagement computing devices. A second group of inventions describedwith reference to FIGS. 1-4 and FIG. 6 relates to systems and processesfor managing groups of rack-mounted computing devices with rackcontrollers and other data center management computing devices. A thirdgroup of inventions described with reference to FIGS. 1-4 and FIGS. 7and 8 relates to systems and processes for managing groups of rackcontrollers and other data center management computing devices. FIGS. 9and 10 address issues with traditional BMCs with techniques to managecomputing device via an external microprocessor that connects to arelatively low-pin-count bus on the device's motherboard. Additionalinventions described take the form of combinations of these groups.

Many extant out-of-band management products have deficiencies. Amongthese problems, the application program interface (API) capabilities ofthese products are lacking. Additionally, many existing out-of-bandmanagement products rely on a wired, Ethernet-based communications busand some variation of a baseboard management controller (BMC) perserver. As a result, many of these systems suffer from reliance on anAPI that is difficult to implement, sensorfication that is typicallylimited to chassis-only (e.g., on the chassis of the rack-mountedcomputing device, rather than on the rack itself or relatedinfrastructure), and reliance on wired connections and a BMC, which mayhave a more limited set of exposed functionality than some embodiments.

Additionally, many data center management products also lack the abilityto sufficiently aggregate and analyze data across a multitude ofservices, including application, operating system, network, buildingmanagement system, hardware, power, fire, and other capabilities. Theability to look “north” and “south” of the rack is an open issue in thedata center market. Typically, significant hardware investment has beennecessary to achieve modest monitoring and control capabilities; theability to provide northbound and southbound management and analyticscapabilities in a variety of form factors (controller, switch module,etc.) has been hard to achieve.

Generally, there is a need for a turn-key, easy-to-operate set ofmanagement, sensorfication and intelligence services that arewell-integrated with hardware like that described herein and used indata centers. This includes supported power, fire, network, and otherancillary equipment, in some embodiments. (This is not to suggest thatsome embodiments do not also suffer from different subsets of theabove-described issues, as the various inventions described herein maybe used to beneficial effect without implementing other inventionsaddressing other problems. Thus, not all embodiments mitigate alldescribed problems, and some embodiments mitigate problems implicitlydescribed that will be apparent to one of ordinary skill in the art.)

In some embodiments, a Data Center Sensorfication, Control, Analyticsand Management Platform, referred to as “Vapor CORE,” mitigates some orall of the problems above by providing a set of services withsouth-of-rack (southbound′) management and monitoring capabilities, aswell as north-of-rack (northbound′) aggregation and analyticscapabilities. In some embodiments, these capabilities are exposed in a‘southbound’ API and ‘northbound’ API, and are supported by a variety oftools and deployment options that can be used to integrate, analyze,visualize and operationalize the data and decisions generated by theAPIs and components. In some embodiments, Vapor CORE's API may beexposed by rack control units or other data center management computingdevices, like those described below and that execute logic to implementthe APIs.

In some embodiments, Vapor CORE is implemented as a set of microservices(e.g., each executing a server monitoring a respective port on arespective computing device and executing code responsive tocommunications received via that port (either loopback or external) andsending output via that port), executing on the rack controllerdescribed below, and deployed and managed automatically by thetechniques described below or those the Crate Configuration, Containerand File management system described in U.S. Patent Application62/275,909, filed 7 Jan. 2016, titled RACK FOR COMPUTING EQUIPMENT, thecontents of which are incorporated by reference above. The services maybe organized in two categories: a southbound API and a northbound API.

The southbound API of Vapor CORE, in some embodiments, provides aRESTful (representational state transfer) API built atop Nginx™ anduWSGI, using Flask as the microdevelopment framework. A Python™ package,in some embodiments, is used to interpret API requests and translatethem into a serial protocol payload, sent over power line communications(PLC) to devices along the serial bus. Response data, in someembodiments, is read from the serial bus, interpreted, and returned tothe API consumer in JSON format. The API capabilities, and correspondingimplementing code, in some embodiments, include:

-   -   Ability to scan or enumerate the devices to gather a full        picture of devices and capabilities available; the results of        the scan, in some embodiments, are returned in an        easy-to-interpret form that allows for easy programmatic access.        These results, in some embodiments, also include locational        information for sensors and devices, for easy mapping and        visualization of every piece of data gathered from the system,        as discussed in U.S. patent application Ser. No. 15/337,732,        filed on 28 Oct. 2016, titled SENSING LOCATION OF RACK        COMPONENTS, the contents of which are hereby incorporated by        reference, and elsewhere in this document with reference to        location-awareness-related sensing.    -   Reading of analog and digital sensors. This, in some        embodiments, involves translating a stream of bytes into a        meaningful and human-understandable response. Sensor support, in        some embodiments, includes humidity, temperature, pressure,        vibration, particulate, noise, and other similar sensors.    -   LED (light emitting diode) control for rack (e.g., wedge) status        communication. The LED light at the top of a rack, in some        embodiments, may be changed in terms of color, illumination, or        blinking to visually communicate rack status. Or audible or        other visual indicators may be actuated.    -   Fan control, including, in some embodiments, getting fan status        in terms of revolutions-per-minute (RPM).    -   Power control and status. This involves, in some embodiments,        sending a command to a device, requesting power on/off/cycle or        status. In some cases, power status is returned and translated        from the power supply's format to a more easily machine- or        human-interpretable form. This, in some embodiments, includes        power status (on/off), power “ok” (true/false), voltage and        current consumption, and whether the power supply registers an        under-voltage or over-current condition.    -   Device inventory, including subcomponent inventory from servers        and devices in the rack. The response, in some embodiments, may        also include Extensible Firmware Interface (EFI) (like Basic        Input/Output System (BIOS) or Unified Extensible Firmware        Interface (UEFI)) information, which may include items such as        Asset Tag and other device-specific information.    -   Boot device selection, allowing, in some embodiments, boot        device to be retrieved from device, as well as for the boot        target to be specified. This, in some embodiments, may be used        for automated provisioning of data center devices.    -   Door lock control. Door locks, in some embodiments, may be        controlled on a rack's front door to allow/deny physical access        to rack contents, as well as to provide an audit trail of        physical access to a given rack. Or some embodiments may        implement U-specific locks that gate access to individual        rack-mounted computing devices.    -   Intelligent Platform Management Bus (IPMB) Communications        Protocol. Some embodiments allow sending/receiving of IPMB        packets over serial bus to carry out standard IPMI commands over        IPMB via a powerline communication (PLC) bus.    -   OCP (Open Compute Project™) debug header POST (power-on        self-test) code retrieval.    -   Firmware flash. Some embodiments allow device firmware to be        remotely updated through the API.    -   Version information about some or all of the following:        endpoint, software, remote device, firmware and API.

Additionally, in some embodiments, the southbound services provided byVapor CORE include serial console access to individual devices in therack. This access, in some embodiments, is provided over PLC as well,and is mapped to virtual TTY devices, that may be accessed locally fromthe rack controller described below, or remotely via secure shell (SSH)to a Transmission Control Protocol (TCP) port on the rack controllerdescribed below. This, in some embodiments, is implemented by mapping aTTY to a device ID, and communicating with rack controller describedbelow to marshal access to the serial console of that device.

The services described above, in some embodiments, are distributed via aDocker™ container, managed by Crate (described below with reference toFIGS. 1-4 and 7-8). Serial console access, in some embodiments, ismanaged by a separate operating system module that scans the bus andcreates and maps the devices based on its interpretation of the scancommand.

In some cases, the southbound API may facilitate the process ofobtaining data from sensors on rack-mounted devices, like servers.Often, sensors impose a large number of steps to convert sensor readingsto things useful to machines or humans, e.g., converting a voltage froma thermocouple to a temperature. To mitigate this issue, someembodiments may identify what type of sensor is present based on a codereturned that indicates the sensor type, which may be obtained based onelectrical characteristics and reading registers, for instance, usingtechniques described below or in U.S. Patent Application 62/275,909, ina section titled “External Access to Local Motherboard Monitoring andControl.” In some embodiments, based on the code, the appropriateconversion may be selected, e.g., volts to degrees Celsius. Someembodiments may use this technique to obtain temperature, humidity,particulate count, airflow rates, etc., as opposed to a voltage or acurrent or other scaled value.

The northbound side of Vapor CORE, in some embodiments, is a separatemicroservice that is designed in a three-level pluggable architectureincluding the following:

-   -   Data source plugins    -   Analytics engine    -   Presentation plugins

Data source plugins, in some embodiments, may be registered with VaporCORE given a standard data source data transformation API and may beused to gather data from a variety of sources in the data center,including, in some embodiments, the southbound API, Crate, buildingmanagement systems, fire suppression and power distribution systems,Bloom box API™, other management and control systems (e.g., Puppet™,Chef™, Ansible™, etc.), IPMI/iLO/DRAC, etc. Registration of components,in some embodiments, includes storage of addressing, credentials andrules for polling, among other things; registration data piggybacks thedata store in the analytics layer, and may be carried out via API oruser interface (UI) (both distributed with Vapor CORE).

In some embodiments, an analytics engine component serves as a primarydata store for Vapor CORE and stores plugin registration, as well asschematized data gathered by plugins. Pre-built analytics routines, insome embodiments, may be included with Vapor CORE to compute metricssuch as price per watt per dollar (price/W/$), cost of cloud, etc.Additional analytics routines, in some embodiments, may be developed bycustomers or solution vendors, and snapped into the analytics engine,bound to the data source plugins registered with Vapor CORE.

Presentation plugins (e.g., executing on a data center managementcomputing device, like those described below, for instance in adashboard application), in some embodiments, may be registered withVapor CORE given a standard presentation plugin API and may be used toexport the result of analytics routines in a variety of forms (e.g. UI,comma separated values (CSV), JavaScript™ Object Notation (JSON),extensible markup language (XML), etc.). Presentation plugins, in someembodiments, are bound to a set of analytics routines and data sourcesstored in the analytics engine, and transform and present the data in avariety of ways. Presentation plugins, in some embodiments, areregistered in a similar manner to data source plugins, and theirregistration also includes configuration of the output mechanism (e.g.TCP port, file, etc.).

In some embodiments, Vapor CORE sits atop a variety of data sources andprovides an endpoint exposing raw, aggregate and computed data pointsthat may be consumed by a higher level tool, such as an orchestration orautomation engine, dashboard, or as a data source input to another VaporCORE instance. Crate and Vapor CORE, in some embodiments, may alsocommunicate reciprocally to inform and perform automated managementtasks related to data center equipment or Vapor components such as VaporEdge Controllers (VECs) and Vapor software.

Vapor CORE, in some embodiments, may exist in a hosted environment, andbe used to remotely monitor and manage a data center, as describedelsewhere herein with reference to Crate.

In some embodiments, Vapor CORE may perform or provide critical (whichis not to imply that it, or any other feature, is required in allembodiments) environment live migration, data center management ordevops capabilities, workload and management capabilities and the like.

In some embodiments, the distributed nature of Vapor CORE and the datacenter racks may allow for strategies for data aggregation and analysisin a decentralized manner. This is expected to allow for the computingresources of the rack controllers to be well-utilized and facilitateoperations at scale.

Some embodiments may be configured to obtain a device inventory and bootselection from rack-mounted devices. For instance, upon scanning (e.g.,an inventory scan for a particular device), some embodiments may accessa system management bus (SMBUS) on the server midplane and retrieve alist of processors and device list seen by the operating system of theserver. In some cases, this data may be acquired from SMBUS withoutusing an agent executing within the operating system or on the CPU ofthe server. Similarly, some embodiments may access this bus tointerrogate and change boot target selection or adjust BIOS (or otherEFI) settings in memory, e.g., for automated provisioning that includesswitching to a different boot target on the network to roll out a newBIOS. In some embodiments, the boot target can be read and set by thesouthbound API, e.g., with a representational state transfer(REST)-based request. Further, some embodiments may perform agentlesssystem monitoring of the operation of the rack-mounted device, e.g.,tracking a server's CPU usage rate and memory consumption, in somecases, without using a BMC. Further, some embodiments may provide forremote console access—remote TTY—over powerline communication. In somecases, because communication occurs via a web proxy, web-based securitytechniques may be employed, like OAuth and Lightweight Directory AccessProtocol (LDAP).

In example use cases of some embodiments, these techniques may be usedto view diagnostic information describing a boot operation. Forinstance, if a machine is power cycled, some embodiments may retrievepower-on self-test (POST) codes for troubleshooting. These techniquesare best understood in view of an example computing environment.

In some cases, the features of Vapor Crate are provided by some of theembodiments described below with reference to FIGS. 1-5 and 7-8, thefeatures of Vapor CORE are provided by some embodiments described belowwith reference to FIGS. 1-4 and 6.

FIG. 1 illustrates a data center 10 configured to mitigate a variety ofproblems, both those explicitly discussed below, and those implicit inthe description and which will be apparent to those of ordinary skill inthe art. In some embodiments, the data center 10 includes a plurality ofracks 12 (e.g., identical racks arranged in a pattern, like arectangular array or hexagonal packing pattern), examples of which aredescribed in each of the applications incorporated by reference, such asthose titled RACK FOR COMPUTING EQUIPMENT.

These applications describe, in certain embodiments, wedge-shaped racksarranged to form chambers, and those wedges may serve as the racksherein. Or the racks may take other forms, e.g., traditional racks,e.g., those with hot aisles, arranged edge-to-edge along linear aisles,either with front-access or rear-access for maintenance.

The racks may house (e.g., mechanically support, cool, and provide dataand power to) a plurality of rack-mounted computing devices 13, anexample of which is described below with reference to FIG. 11. In someembodiments, the data center 10 includes a relatively large number ofracks 12, for example, more than 10, or more than 20, and each rack mayhouse a relatively large number of computing devices 20, for example,more than 10, and in many cases, more than 50. In some cases, therack-mounted computing devices 13 are arranged in discrete units ofspace, called “U's,” for instance in a vertical stack of U's. In somecases, the rack-mounted computing devices are mounted to rails (e.g., ona slideable shelf) and can be slid horizontally outward from the rackfor service. Or in some cases, the racks have U's arrayed horizontally,and rack-mounted computing devices 13 may be slid vertically, upward,like out of a bath of cooling liquid, such as mineral oil. In somecases, a cooling fluid (e.g., liquid or gas) is conducted over therack-mounted computing devices 13 for cooling. Three racks 12 are shown,but embodiments are consistent with a single rack or substantially moreracks. Each rack 12 may include the features illustrated in the enlargedview of one of the racks 12. Data centers provide and use computationalresources (e.g., applications, networks, computing devices, virtualmachines, containers, and the like) in two domains: (i) to providegeneral-purpose computing power (or special-purpose computing power) toa user; and (ii) to manage the data center itself. Accordingly, it ishelpful to define terminology to distinguish between these domains, ascommercial implementations often use different types of resources ineach domain, typically with much less expensive and much less powerfulresources being used for management. These different domains aredistinguished herein by more broadly leveraging the “in-band” and“out-of-band” modifiers used in industry to identify networks servingthese respective domains. Thus, the rack-mounted computing devices 13may execute “in-band” applications that provide the functionality forwhich a data center or rack therein is built, e.g., hosting user-facingsoftware-as-a-service applications or virtual machines, storage, orcontainers provided as service to remote users or applications. This isdistinct from “out-of-band” resources (applications, computing devices,and networks) used to manage the rack-mounted computing devices 13, aspart of the infrastructure of a rack or (i.e., and/or) data center. Insome embodiments, the out-of-band networks have less than ½ thebandwidth of the in-band network, e.g., less than 1/10th. In someembodiments, the out-of-band computing devices (or correspondingconstructs, like virtual machines) have less than ½ the availablefloating-point-operations-per-second than the in-band computing devices,e.g., less than 1/10th. Some embodiments may keep these out-of-bandinfrastructure resources and in-band applications separate, eitherpartially (e.g., with different containers or virtual machines) or fully(e.g., with different computing devices), for security purposes.

To this end and others, some embodiments may include an in-band-network15 (e.g., implemented with network switches 11, like top-of-rackswitches) and an out-of-band network 17, each having a distinct addressspace (e.g., a private Internet-Protocol (IP) subnet or different rangesof public IP addresses), with the former 15 conveying data betweenrack-mounted computing devices 13 or the public Internet 19, and thelatter 17 conveying data within the data center 10 (and in some cases,externally) for purposes of managing the rack-mounted computing devices13 (e.g., monitoring, provisioning, load-balancing, updating, servicing,etc.) and related infrastructure (e.g., monitoring, responding to, andadjusting cooling or power delivery). Keeping the networks 15 and 17(and related computing devices or applications) separate is expected toreduce the likelihood of a penetration of the more externally facingin-band-network 15 resulting in an attacker gaining control of datacenter infrastructure. That said, embodiments are also consistent withconsolidating these networks or different subsets of the out-of-bandresources (e.g., computing devices or applications).

Many traditional out-of-band networks present a number of problems indata center designs. For instance, often switching and wiring isreplicated relative to the in-band-network all the way to the edge ofthe out-of-band networks, often doubling the networking equipment costsand wiring complexity in a data center (which should not be read as adisclaimer, as some embodiments of some inventions described herein areconsistent with this approach).

These problems often co-occur with other undesirable aspects of datacenter hardware. Additional issues include added cost for powerdistribution and conditioning circuitry. In many cases, power isdistributed within a data center via alternating current, whileindividual computing devices generally operate on direct current. Inmany cases, the transition between alternating current and directcurrent is made with computing-device specific AC-to-DC powerconverters. This architecture has the undesirable effect of multiplyingthe number of power converters within a data center, placing a heatsource and electromagnetic radiation source near sensitive computingequipment, occupying valuable rack space, and multiplying the number oflocations were failures may occur in hardware. (These discussions ofproblems with traditional design should not be taken as disclaimers ofsubject matter, as several inventions are described, and they areindependently useful and may be used in environments where some problemspersist while others are addressed.)

To mitigate these issues, in some embodiments, an edge-portion of theout-of-band network may be replaced or supplemented with a plurality ofpowerline communication networks that deliver both data anddirect-current power to a plurality of rack-mounted computing devices.In some cases, each rack 12 may include a (e.g., one and only one, ormore than one) rack-specific powerline network, which may be aDC-powerline network 16. Or in some cases, an individual rack 12 mayinclude a plurality of powerline networks, or a powerline network mayspan multiple racks 12. Or in some cases, a rack 12 may have separatepower-delivery and sub-networks (relative to the out-of-band network 15extending throughout a data center).

Thus, some embodiments may include 1) an in-band-network 15; 2) a datacenter-wide out-of-band network 17; and 3) a plurality ofsub-out-of-band networks 16. Each sub-out-of-band network may have theirown address space distinct from each other and the data center-wideout-of-band network and in-band network 15 (e.g., each using the sameaddresses for different devices on different racks), and eachsub-out-of-band network may provide out-of-band network access formonitoring and controlling a plurality of rack-mounted computing devices13 (e.g., a full-rack) and sensors and other actuators associated withthe plurality of rack compute units 20 (e.g., associated with the rack).

To these ends and others, an alternating-current-to-direct-currentconverter 14 may deliver direct current to each of the racks 12 via abus 16 that also conveys data. In some embodiments, each rack 12 mayinclude its own dedicated converter 14 that services a collection ofcomputing devices on the rack, or in some cases several racks 12 mayshare a converter 14. In some embodiments, converter 14 includes arectifier, step down transformer, and low-pass filter operative todeliver, for example, to racks 12, direct current power. Rack-specificconverters are expected to segment the media for out-of-band datasignaling, reduce the number of users of the address space on the media,and permit simplified and less expensive circuitry for the devicescommunicating on the DC power bus, but embodiments are also consistentwith busses shared across racks. Having consolidated AC-to-DC convertersfor a collection of computing devices (e.g., a full rack) is expected toavoid the cost and thermal load arising from performing the conversionat each computing device with a dedicated converter, though embodimentsare also consistent with this implementation. Some embodiments may haveone AC-to-DC converters per plurality of rack-mounted computing devices13, e.g., one per rack, or one per collection of racks. In some cases,data may be conveyed via an AC powerline network.

In some embodiments, direct-current power is distributed throughout arack 12 via a direct current power bus 16. In some cases, thedirect-current power bus 16 includes two distinct conductors, forexample, carrying ground and a 12-volt or 48-volt potential with two andonly two conductors along a terminal portion of a path to a devicereceiving power and data at an edge of the sub-out-of-band networkformed by bus 16. In some embodiments, each rack 12 may include the DCbus 16, or a dedicated DC bus 16 specific to that rack, for example, tomaintain and address space within a rack that is distinct from that ofother racks and simplify signaling protocols (e.g., by reducing thenumber of devices contending for a given instance of the network medium)and reduce cost of associated circuitry.

In the illustrated embodiment, racks 12 each include a rack control unit18, a plurality of rack-mounted computing devices 13, a plurality ofsensors 21, and a plurality of actuators 23. The racks 12 may have aplurality of rack computing units 20, e.g., each being one U and havingone or more of the rack-mounted computing device 13 along withdevice-specific support hardware, like the adapters 30 described below.Two units 20 are illustrated, but embodiments are consistent withsubstantially more, for example, on the order of 8 or more per rack.Some embodiments may have multiple rack-mounted computing devices 13 perunit 20, or multiple units 20 per device 13.

In some embodiments, the rack control unit 18 is a type of data centermanagement computing device and, thus, may exercise local control andmonitoring (e.g., without directly monitoring or controlling devices inother racks—though embodiments are also consistent with this) over theoperation of devices 20, 21, and 23 in the rack 12 (and performoperations distinct from a network switch that routes in-band data), andeach rack 12 may include its own independent rack control unit 18. Inother cases, the data center management computing device may berack-mounted computing device executing a rack controller that exerciselocal control and monitoring (which is not to imply that monitoring isnot an aspect of or form of control).

In some embodiments, the rack control units 18 may operate as gatewaysbetween an Ethernet out-of-band network 17 and a DC power bus networks16, for example, specific to each rack 12. In some embodiments, the outof band Ethernet network 17 may connect each of the racks 12 via theirrack control unit 18, and the data center may be managed via networks 16and 17, with monitoring data being sent back to a data center managementcomputing device 25 via networks 16 and 17 and commands beingdistributed via network 17 for implementation by controllers 18 andnetworks 16.

Sensors 21 may be any of a variety of different types of sensors, likethose described below as being associated with rack computing units 20.Examples include temperature, particulate, vibration, humidity, optical,and other sensors. In some cases, the sensors 21 are secured to the rack12 itself, rather than a computing unit 20 or device 13 (e.g., thedevice 13 can be removed and the sensor 21 would remain on the rack, andthe sensor 21 may be on the rack before any devices 13 are installed).In some cases, the sensors 21 are not specific to an individualcomputing unit 20 or device 13. Or some embodiments may include, as partof the rack 12, one or more sensors for each U in the rack 12, e.g., alocation sensor like those described in U.S. patent application Ser. No.15/337,732, filed 28 Oct. 2016, titled SENSING LOCATION OF RACKCOMPONENTS, the contents of which are incorporated by reference.

In some cases, the sensors 20 sense an attribute of the rack and itsenvironment and send signals indicative of measurements via network 16to controller 24. In some cases, some sensors 20 are based onmicrocontrollers rather than full computers (having an operating systemexecuted on a microprocessor) to sense and report values withoutincurring the cost and thermal load associated with a full computer(though embodiments are also consistent with this approach).

Actuators 23 may have features similar to the sensors 21 in the sensethat some are microcontroller-based, some are distinct from units 20 anddevices 13, and some draw power from the network 16 for similar reasons.In some cases, the actuators 23 are controlled by the rack control unit18, e.g., reporting via network 16 a physical state of the sensor,receiving a command to change that state via network 16, and effectingthe change with power from the network 16. A variety of different typesof actuators may be included. Examples include a fire-suppressionactuator operative to release a fire-suppression chemical (e.g., a gasor foam). Other examples include an actuator operative to adjust coolingfluid flow (e.g., a solenoid configured to cause rotation or translationof components of the spatially modulated airflow restrictors describedin U.S. patent application Ser. No. 15/065,201, filed 9 Mar. 2016,titled COOLING SYSTEM FOR DATA CENTER RACK, the contents of which arehereby incorporated by reference) in a selected part or all of a rack(like responsive to a fire being detected to remove airflow orresponsive to a temperature sensor in a rack indicating higher-localtemperatures). For instance, some embodiments may detect a highertemperature in an upper part of one rack with a sensor 21 than a lowerpart, and with controller 18, instruct an actuator 23 to adjust a ventto afford greater airflow in the upper part or restrict airflow in thelower part (or other fluids). In another example, some embodiments mayinclude a locking actuator, e.g., a pin driven by a solenoid biased openor closed by a spring into an aperture in an otherwise moveablecomponent, and the lock may lock a given computing unit 20 shelf inplace or a rack door closed, thereby providing physical security. Insome cases, a sensor on the face of a rack may include anear-field-communication (NFC) sensor by which a technician's NFC card(or mobile device) is scanned to authenticate access, thereby limitingphysical access to those authorized and providing an audit trail for whoaccessed what when.

In some cases, the sensors 21 and actuators 23 may be powered by andcommunicate with the network 16. Having distributed DC power and networkcommunication available is expected to facilitate the use of denser andmore widely distributed networks of sensors and actuators than isfeasible in traditional designs in which each sensor would need its ownAC-to-DC power source and an Ethernet network interface, adding cost andthermal load (though not all embodiments afford this benefit, which isnot to imply that other features may not also be varied). In some cases,sensors 21 and actuators 23 may be operative without regard to whether arack computing unit 20 is present or on, thereby providing sensing andcontrol that is robust to crashes or lower-density deployments.

In some embodiments, remote terminal sessions, for example, may bemaintained between the administrator's computer 25 connected to network17 and individual rack computing units 20 via networks 17 and 16. Insome embodiments, rack control units 18 may monitor the operation andpresence of rack computing units 20 and, in some cases, components ofthose rack computing units 20, via the powerline communication bus 16.In some embodiments, the rack control unit 18 may be configured toperiodically poll existing devices on the network 16 and report back vianetwork 17 the result of the poll to device 25. In some cases, rackcontrol units 18 may periodically request, from each rack computing unit20 via the DC power bus 16, the status of various sensors, such astemperature sensors, vibration sensors, particulate sensors, fan speedsensors, airflow sensors, humidity sensors, air pressure sensors, noisesensors, and the like. In some embodiments, rack control unit 18 maycompare the reported values to a threshold and raise or log variousalarms, for example, via network 17, to bring a condition to theattention of an administrator. Similarly, in some cases, rack controlunit 18 may implement various changes on rack computing units 20 by acommand sent via network 16. Examples include instructing rack computingunits to boot up or turn off, update an EFI, change a setting inpersistent flash memory (in some cases bypassing the EFI), update orreport a firmware version, change a register value in a peripheral, andinitiating and executing a remote terminal session. In some embodiments,rack control unit 18 and network 16 are operative to exercise controlover the rack computing units 20 even when the computing devices, suchas servers of those rack computing units, are turned off. This isexpected to reduce the burden on maintenance personnel, as certainoperations can be performed remotely, even in scenarios in which thecomputing devices are turned off.

In some embodiments, rack computing units 20 each occupy a respectiveshelf or a receptacle, such as a “U,” in the rack. In some embodiments,each rack computing unit includes a distinct computer, having adedicated processor and memory that operates to execute an operatingsystem and application within a distinct memory address space. Any of avariety of applications may be executed, including web servers,databases, simulations, and the like, in some cases in virtualizedcomputing devices or containers. In some cases, the rack-mountedcomputing devices 13 in each unit 20 are general purpose computers, orsome embodiments may include special purpose computers, such asgraphical processing units, bitcoin mining application specificintegrated circuits, or low-floating-point precision (e.g., less than 16bit) ASICS for machine learning. In some embodiments, the applicationsmay communicate with one another and remote users via the in-bandnetwork 15 that conveys the data the computing devices operates upon,which stands in contrast to the management data by which the computingdevices are managed and monitored via the out-of-band network 17.

In the illustrated embodiment, rack control unit 18 includes a rackcontroller 24, and out-of-band network interface 26, and a powerlinemodem 28. In some embodiments, the rack controller 24 may implement thelogical functions described above and below, for example, for monitoringthe rack computing units 20 and sensors 21, controlling the rackcomputing units 20 and actuators 23, and translating between thenetworks 16 and 17. In some embodiments, the rack controller 24 mayexecute routines that control, engage, and disengage various thermalcontrol units, such as fans or adjustable airflow restrictors, thatmaintain the temperature of the rack computing units 20, for example,responsive to temperature sensors on the units 20 indicating animbalance in airflow or positive pressure in an exhaust region. In someembodiments, the rack controller 24 is an application executing on adistinct computing device having a processor, memory, and an operatingsystem, and such as a computer serving as the rack control unit 18without hosting in-band applications, e.g., one provided with the rack12 before in-band computing devices are installed. In some embodiments,the rack controller 24 includes a REST-based web server interfaceoperative to receive instructions and provide responses on the network17 according to a RESTful API. In some cases, the REST-based API mayface the out-of-band network 17, receiving API requests via this networkfrom other rack control units 18 or the administrator computing device25.

In some embodiments, the out-of-band network interface 26 is an Ethernetnetwork interface having an associated driver executing in the operatingsystem of the rack controller 24 and configured to move data betweenbuffer memory of the network interface and system memory, e.g., withdirect memory access, and provide interrupts indicative of suchmovements. In some cases, the out-of-band network interface 26 connectsto an Ethernet cable, such as a CATS (category 5), or CAT6 (category 6)cable connecting to the other racks 12.

In some embodiments, the various devices on the DC power bus 16,including the rack control unit 18, include a powerline modem 28. Insome embodiments, the powerline modem 28 is a direct current powerlinemodem operative to encode data on top of a direct current power source.(Signals readily separated from the DC power, e.g., at higher than athreshold frequency or less than a threshold root-mean-square deviationfor the median, do not transform the DC power to AC power.) In someembodiments, the data is transmitted by applying an electrical stimulusto the electrical conductors conveying direct current power. Thestimulus may take any of a number of different forms. Examples includeselectively connecting a higher or lower voltage to the conductors,thereby pulling the voltage up or down in a manner that may be sensed byother powerline modems. Other examples include selectively connecting acurrent source or drain to the conductors of the DC power bus 16,thereby again imparting an electrical signal on top of the DC power thatmay be sensed by other computing devices. In some embodiments, animpedance may be selectively coupled to the DC power bus, thereby, forexample, affecting fluctuations imposed on top of the DC power bus in amanner that may be sensed by other powerline modems.

In some embodiments, the electrical stimulus is a time varyingelectrical stimulus. Data may be encoded by varying the electricalstimulus a number of different ways. In some embodiments, the stimulusmay simply be turned on and off according to a clock signal, like with asquare wave, and data may be conveyed by determining during each clockcycle whether the stimulus is applied or not, indicating a zero or one.In other examples, the stimulus may be used to adjust an attribute of awave, like a carrier wave, maintained on the DC power bus. For example,data may be encoded with pulse width modulation, by applying a squarewave to the DC power bus and adjusting the time of a falling edge of thesquare wave according to whether a zero or one is being transmitted.Other examples may adjust a rising edge of the square wave or a dutycycle of the square wave or other waveforms. In some embodiments,multiple attributes may be adjusted, for example varying in amplitude ofthe wave, a duty cycle of the wave, and times for falling or risingedges of the wave to encode additional data in a more compact form.

In some embodiments, at the same time data is being conveyed on the DCpower bus, DC power is also being conveyed. In some embodiments, thedata signals may be configured such that they do not interfere with thedelivery of DC power. For example, the time varying electrical stimulusmay change the DC voltage or current by less than a threshold percentageof what is delivered, for example with a RMS value less than 10% of themedian, such that filtering can readily remove the data signal fromelectrical power being delivered to computing devices that are oftensensitive to variations in electrical power. In other embodiments, thespeed with which the data is conveyed, or a carrier wave, may be at afrequency such that low-pass filters can readily distinguish between theDC power component and the data component.

In some embodiments, to facilitate separation of data from power, thedata may be encoded with pulse width modulation, such thatdata-dependent effects are less likely to interfere with power delivery.For example, absent a carrier wave, a relatively long string of ones orzeros that are consecutive may cause power to fluctuate on thedownstream side of a low-pass filter, resulting in low-frequencyincreases or decreases in voltage of the DC powerline that may penetratea low-pass filter. In contrast, pulse width modulation maintains arelatively uniform average voltage after a low-pass filter is applied,as the frequency of the pulses that are modulated may be selected suchthat they are readily separated from the underlying DC power signal.

In some embodiments, access to the DC power bus as a medium for datatransmission may be arbitrated with a variety of techniques. Examplesinclude time division multiplexing, code division multiplexing,frequency division multiplexing, orthogonal frequency-divisionmultiplexing, and the like. In some implementations, it is expected thatthe bandwidth requirements for the network 16 will be very low (e.g.,less than 100 kilobits per second), and an encoding scheme may beselected to reduce the cost of the associated circuitry. For example, insome implementations, the speed and cost of Ethernet connections may beexcessive relative to the requirements for signaling. In contrast,relatively low bandwidth time division multiplexing circuitry on asynchronous network is expected to cost substantially less while stillproviding adequate bandwidth. This is not to suggest that embodimentsare inconsistent with higher bandwidth architectures. It should be notedthat many in the industry have persistently failed to recognize thisopportunity for cost reduction and circuitry simplification.

In some embodiments, each powerline modem 28 may select a duration oftime over some cycle in which that powerline modem on the network 16 ispermitted to transmit, e.g., in the event that the powerline modem doesnot detect that another device on the network currently has control ofthe media. In some embodiments, a device has control of the media if ithas received a request on the network 16 and has not yet responded. Insome embodiments, the network may be a synchronous network. In someembodiments, the duration of time dedicated for each powerline modem onthe network 16 to transmit when the media is unclaimed may be selectedbased on a factory set value, like a media access (MAC) address,initially.

In some embodiments, an ad hoc mechanism may be used to deal withcollisions, in which multiple devices have selected the same duration oftime. In some embodiments, the powerline modem 28 may be operative todetect when another device is transmitting at the same time, and inresponse, select a different duration of time, for example, randomly(like pseudo-randomly or by seeding a linear shift register with lesssignificant digits of a reading from a temperature sensor). Forinstance, powerline modem 28 may have reserved as its time to transmitbetween zero and 100 milliseconds (ms) after some timing signal, while apowerline modem of a first rack control unit may have reserved as itstime to transmit 100 ms to 200 ms, and a different rack computing unitmay have as its time to transmit 300 ms to 400 ms. Collisions occur whentwo devices select the same duration of time, and a randomizedre-selection may alleviate the conflict without a central authorityallocating time slots. Selecting transmission durations in an ad hocfashion is expected to substantially lower the cost of maintenance andsimplify installation, as devices can be installed on the network 16without additional configuration, in some embodiments. That said, notall embodiments provide this benefit, as several inventions aredescribed that are independently useful.

In some embodiments, the modem 28 may encode data and commands in aparticular format, for example, in packets having headers with anaddress of the receiving and transmitting devices. In some embodiments,each powerline modem on the network 16 may receive signals and determinewhether the signal includes a packet having a header designated for thatdevice. In some embodiments, the packets may include error correctionand detection, for example, with parity bits, Hamming codes, or otherredundant lower entropy encoding.

A variety of techniques may be used to receive signals. For example,some embodiments may apply the signal on the DC power bus 16 to alow-pass filter and then compare the filtered signal to the signal onthe DC power bus 16 to determine a differential signal having, forexample, a higher frequency component conveying data. In some cases, thedifferential may be compared to a threshold to determine whether a zeroor one is being transmitted. Or a pulse-width modulated signal may becompared to an unmodulated signal of the same underlying frequency, andchanges in edge timing may produce a signal that, when compared to athreshold, indicates a zero or one.

In some embodiments, the signals may correspond to those traditionallyused in RS232 connections to facilitate re-use of existing hardware andsoftware. Examples include the Data Terminal Ready signal, indicatingthat data terminal equipment (DTE) is ready to receive, initiate, orcontinue a call; the Data Carrier Detect signal, indicating a datacircuit-terminating equipment (DCE) is receiving a carrier from a remoteDCE; Data Set Ready, indicating that DCE is ready to receive commands ordata; Request to Send, indicating that a DTE requests the DCE prepare totransmit data; Request to Receive, indicating that a DTE is ready toreceive data from a DCE; Transmitted Data, carrying data from the DTE toDCE; and Received Data, carrying data from the DCE to the DTE.

In some embodiments, communication may be via request and response,where once a request is sent by one device on the network 16, therecipient device has the exclusive right to transmit on the network 16until a response is sent. Or some embodiments may use a master-slavearchitecture, where, for example, the powerline modem 28 of the rackcontrol unit 18 arbitrates which device communicates on the network 16and when. Request and response synchronous architectures, however, areexpected to allow for relatively simple and inexpensive circuitry, whichmay be favorable in some implementations.

As illustrated, in some embodiments, each rack computing unit 20 mayinclude a network and power adapter 30 and a rack-mounted computingdevice 13 (a term that is reserved herein for in-band computing devices(which may be hybrid devices that also execute out-of-band applicationsin some embodiments like those described with reference to FIGS. 3 and4)). In some embodiments, the network and power adapter 30 may separateDC power and data from the DC power bus 16, provide the power to therack-mounted computing device 13, and process the data to implementvarious routines locally with logic that is independent of therack-mounted computing device 13 and operates even when the rack-mountedcomputing device 13 is turned off.

In the illustrated embodiment, the network and power adapter 30 includesa low-pass filter 34, a powerline modem 36, and a microcontroller 38. Insome embodiments, these components 34, 36, and 38 may be mounted to aprinted circuit board that is distinct from a motherboard of therack-mounted computing device 13 and couples, for example, via a cable,to the motherboard of the device 13. In some embodiments, the low-passfilter 34 may be operative to receive the DC power from the DC power bus16, having the data signals overlaid there on, and remove the datasignals to transmit a smooth, high quality DC power source to therack-mounted computing device 13. A variety of techniques may be used toimplement the low-pass DC filter 34. In some embodiments, an inductormay be placed in series between the bus 16 and the rack-mountedcomputing device 13 to provide a relatively large impedance therebetweenand reduce the power required to drive data signals onto the bus 16 andprotect associated driver circuitry. In other embodiments, the low-passDC filter 34 may also include a resistor placed in series between thebus 16 in the rack-mounted computing device 13, with a capacitor placedbetween a ground and high voltage signal of the bus to, again, providean impedance to reduce the power requirements to drive data signals,while smoothing fluctuations.

In some embodiments, the powerline modem 36 is substantially similar tothe powerline modem 28 described above and may implement the sameprotocols. In some embodiments, each rack computing unit 20 containssimilar or the same features.

In some embodiments, the microcontroller 38 is operative to receivesignals from the powerline modem 36 and take responsive action. In someembodiments, the microcontroller 38 monitors addresses in headers onpackets received via the powerline modem 36 and determines whether theaddress corresponds to the rack computing unit 20. In some embodiments,the address is stored in persistent flash memory of the microcontroller38, for example, in flash memory set with a serial number or MAC addressset at the factory. In some embodiments, upon initially detecting thatthe network and power adapter 30 is connected to a DC power bus 16, themicrocontroller 38 may broadcast is address to the other devices, forexample, to add the address to a list of addresses maintained by therack control unit 18 as received via the powerline modem 28.

In some embodiments, the microcontroller 38 may receive commands fromthe rack control unit 18 and implement those commands, for example, byquerying or otherwise polling various sensors, like those describedabove, to monitor things like resources being used by the rack computingunit 20 (e.g. processor usage or memory usage), or environmentalconditions, like temperature, vibrations, airflow, particulates,humidity, electromagnetic radiation, and the like. In some embodiments,the microcontroller 38 may be operative to drive various signals intothe rack-mounted computing device 13 that reconfigure the rack-mountedcomputing device 13, monitor the rack-mounted computing device 13, orcontrol the rack-mounted computing device 13. Examples include sendingsignals onto a system management bus or other bus of the rack-mountedcomputing device 13 that cause the rack-mounted computing device 13 toturn on, turn off, change a setting accessible via a BIOS (in some caseswithout engaging the BIOS and writing directly to flash memory),reconfiguring various settings, like clock speed or register settingsfor peripheral devices. In some embodiments, the microcontroller 38 isoperative to poll various sensors that indicate the location of the rackcomputing unit 20, for example, by reading a value with an opticalsensor or a radio frequency sensor disposed on a rack that indicates thelocation of a rack computing unit 20 adjacent that device.

In some embodiments, the rack-mounted computing device 13 is a server(e.g., a computer executing a server application), database, or node ina compute cluster that performs operations requested by users of thedata center 10. Examples include serving webpages, servicing queries,processing API requests, performing simulations, and the like. Suchcomputing operations are distinct from those performed to manage andcontrol the operation of computing devices, for example, by changingversions of operating systems, updating or reconfiguring a BIOS, readingsensors, controlling fans, monitoring thermal conditions, and the like.

In the illustrated embodiment, each rack-mounted computing device 13includes persistent memory 40, a processor 42, dynamic memory 44, and anin-band network interface 46. In some embodiments, these components maybe accessed by the microcontroller 38 via a system management bus 48 orvarious other onboard buses. In some embodiments, the components 40, 42,44, and 46 may reside on a single monolithic motherboard, connected viasoldered connections and conductive traces in a printed circuit board.In some embodiments, the persistent memory 40 is flash memory havingvarious values by which the rack-mounted computing device 13 isconfigured, for example, by changing settings in a BIOS. In someembodiments, the processor 42 is one or more central processing units orgraphics processing units. In some embodiments, the dynamic memory 44contains memory used by the operating system and applications, in somecases having an address space distinct from the computing devices ofother rack computing units.

In some embodiments, the in-band network interface 46 is an Ethernetnetwork interface operable to communicate on a distinct Ethernet networkfrom the networks 16 and 17. Separating these networks is expected tomake the data center 10 more robust to attacks and facilitate operationseven when the in-band network is disabled. Further, in some cases, thein-band network may be substantially higher bandwidth and use moreexpensive equipment than the out-of-band management networks 17 and 16.In some embodiments, the network 15 connected to interface 46 may conveythe data upon which the applications operate, for example, at therequest of users of the data center 10.

FIG. 2 another embodiment of a data center 27 having the featuresdescribed above, except that the out-of-band network 17 extends to therack-mounted computing devices 13. Thus, the rack controller 24communicates with rack-mounted computing devices 13 directly, via theout-of-band network 17, rather than via the powerline communicationnetwork. In other embodiments, a separate Ethernet network specific tothe rack is implemented in place of the power line network describedabove. In this example, the rack-mounted computing devices 13 mayinclude an out-of-band network interface 29 with which the computingdevice 13 communicates with the rack controller 24. In some embodiments,each computing device 13 may include a baseboard management controllerthat communicates with the rack controller 24 via the out-of-bandnetwork interface 29. In some cases, an Intelligent Platform ManagementInterface (IPMI) API supported by the BMC may expose various functionsby which the rack controller 24 takes inventory of devices onmotherboards of the computing devices 13, reads values from sensors(like temperature sensors), reads values of registers and configures andchanges these values, in some cases, changing settings including EFIsettings. In some embodiments, the BMC is a separate processor fromprocessor 42 executing an in-band application, and the BMC communicateswith various devices on the motherboard via the SMBus.

FIG. 3 shows another embodiment of a data center 51 in which theabove-described rack controller is executed by one of the rack-mountedcomputing devices 31 (which may otherwise have the features of device 13described above). In some cases, software instructions to implement therack controller 33 may be stored in memory 40 and executed by processor42 of the rack-mounted computing device 31. In some cases, the rackcontroller 33 may be executed in a dedicated virtual machine,microkernel, or container of the rack-mounted computing device 31, withother instances of these computing constructs executing otherapplications, in some cases executing in-band applications. In someembodiments, one rack controller 33 may be executed by one (e.g., oneand only one) rack-mounted computing device on a given rack to monitorother rack-mounted computing devices 13 on that rack 12. Or multipleinstances per rack may be executed. Again, in this example, theout-of-band network 17 may extend to the rack-mounted computing devices13 and 31, in some cases without passing through a power linecommunication network.

FIG. 4 shows another embodiment of a data center 35 in which the presenttechniques may be implemented. In this example, the rack controller 37(e.g., having the features of the rack controllers described above) maybe executed by one of the rack-mounted computing devices 41 (otherwisehaving the features of device 13 above), by executing corresponding codein persistent memory 40 with a processor 42, in some cases within adedicated virtual machine, container, or microkernel, e.g., in thearrangement described above for FIG. 3. In this example, the rackcontroller 37 may communicate with rack controllers on other racks 12via the out-of-band network interface 39 of the rack-mounted computingdevice 41 via the out-of-band network 12. Further, the rack controller37 executed by the rack-mounted computing device 41 may control otherrack-mounted computing devices 13 of the rack 12 via the rack-specificpower line communication network 16 and corresponding instances of thenetwork and power adapter 30 described above.

FIG. 5 illustrates an example of a process 50 that may be performed bysome embodiments of the above-described network and power adapter 30 inrack computing units 20. In some embodiments, steps for performing theprocess 50, or the other functionality described herein, are encoded asinstructions on a tangible, non-transitory, machine-readable media, suchthat when the instructions are read and executed by one or moreprocessors, the associated functionality occurs.

In some embodiments, the process 50 includes receiving, with a givenrack computing unit, direct current power via a DC bus connected to aplurality of rack computing units of a rack and configured to deliver DCpower to the plurality of rack computing units, as indicated by block52.

In some embodiments, the process 50 further includes determining that aduration of time designated for the given rack computing unit to accessthe DC power bus for transmission is occurring, as indicated by block54. Next, in response to the determination, some embodiments may apply atime-varying electrical stimulus to the DC power bus, as indicated byblock 56. In some cases, the time-varying electrical stimulus encodes anaddress on the DC power bus of a rack controller and a sensormeasurement indicative of operation of the given rack computing unit. Inother cases, the stimulus may encode control signals rather than datasignals. Next, concurrent with applying the time-varying electricalstimulus, some embodiments include filtering voltage fluctuations of theDC power bus resulting from the time-varying electrical stimulus toproduce electric power used by the given rack computing unit, asindicated by block 58. Producing electrical power does not require thatthe power be generated, merely that power obtained from some source beconditioned properly for usage by the rack computing unit.

FIG. 6 is a flowchart of an example of a process 60 that may be executedby one of the above-described rack controllers 24 (executed in variousforms of data center management devices, e.g., rack control units 18 orrack-mounted computing devices 13 executing a rack controller 24) inorder to monitor and otherwise control a subset of a data center (e.g. arack) responsive to commands from other subsets of the data center orthe above-described administrator computing device 25, e.g. beingoperated by an administrator. In some embodiments, the process 60 mayimplement the northbound and southbound APIs described above, forinstance, with the northbound API facing the network 17 and thesouthbound API facing the network 16. In some embodiments, an instanceof the process 60 may be executed by a different computing deviceassociated with each rack 12 shown in FIGS. 1-4. In some embodiments,API requests may be sent from one rack controller 24 to another rackcontroller 24 or from the administrator computing device 25, forinstance. In some embodiments, the process 60 may be executed ongoing,for instance, listening to a port on the out-of-band network interface26 on the out-of-band network 17 and responding to API requests as theyare received. In some embodiments, the process 60 may be part of anevent processing loop in which API requests are handled, in some caseswith a nonblocking server using deferreds.

In some embodiments, the process 60 includes receiving an API requestvia a first out-of-band network, as indicated by block 62. In someembodiments, this API request may be one of the above-describednorthbound API requests received by the rack controllers 18. In someembodiments, the API request is received via an Ethernet network that isdistinct from the in-band network described above, or some embodimentsmay receive the API requests from the in-band network in cases in whichthe networks have been consolidated. In some embodiments, the APIrequest is a REST-based request encoded in hypertext transport protocol(HTTP), for instance as a POST or GET request received by a serverexecuted by the rack controller 24 described above. Some embodiments mayparse received requests and take responsive action, for instance, via acommon Gateway interface (CGI) routine. In some cases, requests maycontain both commands and parameters of those commands, for instance,separated from the command with the delimiter like “?” and havingkey-value pairs. In some cases, these parameters may specify aparticular device, such as a particular rack-mounted computing device ona rack, or in some cases, these parameters may specify various otherattributes by which actions are taken. Using a REST-based API, with HTTPformatted exchanges, over an Ethernet-implemented IP network, isexpected to facilitate reuse of other tools built for the data centerecosystem, thereby lowering costs and providing a relativelyfeature-rich implementation, though it should be noted that embodimentsare not limited to systems providing these benefits or implementingthese protocols, which is not to imply that any other feature islimiting in all embodiments.

Next, some embodiments may select, based on the API request, a routineto control rack-mounted computing devices, as indicated by block 64.Control may include reading data from such devices or associated sensorsor actuators either on the rack-computing devices or on the rack itself,whether associated with a specific rack-mounted computing device or withthe rack generally. Control may also include sending commands to writeto, reconfigure, or otherwise actuate such devices, for instance, inaccordance with the routines described herein, and including instructingcomputing devices to power cycle, updating firmware in rack-mountedcomputing devices or the various sensors or actuators, reconfiguringfirmware or EFI settings, actuating fans, solenoids, electromagnets,lights, and the like. In some embodiments, the routine is selected basedon text parsed from the API request, and in some embodiments, theroutine is a script selected by a server that received the API requestexecuted by a rack-controller 24. In some embodiments, selecting theroutine includes calling the routine with parameters parsed from the APIrequest as arguments in the function call.

In some embodiments, selecting a routine may include selecting a routinethat takes action via a different network from the network with whichthe API request was received. In some cases, this different network maybe a powerline communication network like those described above withreference to FIGS. 1, 4, and 5, but embodiments are consistent withother implementations, e.g., like those in FIGS. 2 and 3. For instance,in some cases, the other network is a network implemented with Ethernet,RS-232, USB, and the like. Or in some embodiments, the other network isthe same, for instance, a branch of the network with which the APIrequest is received. In some cases, this other network connects to eachof a plurality of computing devices on the rack and various sensors andactuators associated with the rack, for instance, in accordance with thetechniques described above with reference to network 16 in FIG. 1.

In some embodiments, selecting a routine includes selecting a routinethat reads a sensor via the other network on one or more of therack-mounted computing devices. In some cases, this may include sendinga command to the above-described network and power adapters 30 thatcause the above-described microcontroller 38 to query sensor data viaSMBus 48 (as shown in FIG. 1). In some cases, the sensor is on amotherboard or a chassis of the rack computing unit 20 described above,for instance sharing an output of the low-pass DC filter 34 describedabove with the rack-mounted computing unit 13 (as shown in FIG. 1).

In some embodiments, the routine selected is a routine that reads asensor via the other network on the rack. In some embodiments, thesensor is not itself mounted to a rack control unit or powered by anoutput of a specific low-pass DC filter of a rack computing unit 20. Forinstance, some embodiments may read a value from a sensor on a rack thatmeasures temperature, humidity, airflow, vibration, or particles, andopen or close a lock state of a lock for a door or drawer, or the like.In some cases, the sensor is a sensor that reads and identifierindicative of the location of a given computing device in the rack, inaccordance with the techniques described above.

In some embodiments, reading a value from a sensor may includeprocessing that value before sending a response to the API request onthe network 17 described above. Processing may take various forms,depending upon the embodiment and may include, in some cases, convertingan electrical property, like resistance, capacitance, inductance,current, frequency, or voltage, to some other physical propertycorrelated with the electrical property. For example, some embodimentsmay convert one or more of these values into units of temperature (likedegrees Celsius or Fahrenheit), into units of humidity, into units ofvibration (e.g. RPMs), into Boolean values indicating whether doors areopen or closed locked or unlocked, and the like. In some cases,processing may include combining readings from multiple sensors orcombining readings from a given sensor over time, for instance,selecting a largest or smallest value, calculating statistics on thesensor output like standard deviation or mean, and comparing sensorreadings (such as these statistics) to various thresholds, for instance,to determine whether to respond with an alarm or emit an alarm even inthe absence of a recent API request when a reading is above or below athreshold.

In some embodiments, the routines may be selected based on a scheduledAPI request (including an internal API request obtained via a loopbackIP address) rather than a user-driven API request, for instanceaccording to a cron process run by the rack controller to periodicallyread values from sensors and compare those values thresholds formonitoring purposes or logging those values and reporting those valuesto the data center management computing device 25. Or in some cases,these periodic requests may be received from a corresponding processthat periodically automatically sends API requests from theadministrator computing device 25 for monitoring purposes, for instanceto update a dashboard. In either case, the request initiating action maystill be an API request, such as one sent to a loopback address on anetwork interface coupled to the network 17 described above.

In some embodiments, the routine may be a routine that scans electronicdevices on the second network and produces an inventory of theelectronic devices on that network, such as computing devices, sensors,and actuators on the powerline communication network 16 described aboveor computing devices on SMBus 48 described above.

In some embodiments, the routine may be a routine that changes aconfiguration of an EFI of a given one of the rack-mounted computingdevices, for instance one that changes the same configuration on each ofthe rack-mounted computing devices. For example, some embodiments maychange a boot target of the EFI, such that when the rack-mountedcomputing device is power cycled (or otherwise rebooted), thecorresponding processor may look to a different media indicated by thenew boot target when loading an operating system.

Some embodiments may send operating system updates to the rackcontroller, which may store those operating up system updates on aninstance of this alternate media (such as a different disk drive,solid-state drive, or the like) on each of the rack-mounted computingdevices before changing a boot target on each of those computing devicesand commanding the computing devices to reboot to implement the newoperating system with a reboot. In another example, some embodiments mayupdate applications in this fashion, for instance by downloading animage of a new operating system or container with the new version of anapplication to alternate media and then changing the boot target to thatalternate media. In some cases, these changes may be effectuated withoutinterfacing with an operating system of the computing device 13receiving the change. Similar techniques may be used to update firmwareof peripheral devices.

Next, some embodiments may execute the selected routine, as indicated byblock 66. In some embodiments, the routine may be executed by the rackcontroller described above. In some embodiments, this may includesending a sequence of commands via the second network, such as network16 described above, and in some cases, these commands may be received bythe network and power adapters 30, which may respond by executing theirown routines with microcontroller 38 to effectuate various actions viaSMBus 48 or other interfaces. In other examples, the above-describedsensors 21 or actuators 23 may receive the corresponding commands viathe network 16 (which again, maybe a powerline communication network orother form of network), and the functionality described above may beimplemented at the direction of a rack controller 24. In the course ofexecuting the routine, some embodiments may send commands via a secondout-of-band network to effectuate an action indicated by the APIrequest, as indicated by block 68. For instance, the routine may includea query for values in registers of computing devices (or componentsthereof) or an inventory of such devices or components. Or the routinemay include instructions to change a configuration of these devices, orread a sensor, or actuate an actuator. Other examples are describedabove. The routine may include operations that cause these commands tobe sent and responses to be processed, consistent with the approachesdescribed above.

In some embodiments, the rack controller 24 may perform agentlessmonitoring of the rack-mounted computing devices 13 via the networks 16and 48 described above. For example, some embodiments may read variousvalues indicative of the performance of the computing device, liketemperature, processor utilization, fan speed, memory utilization,bandwidth utilization on the in-band network 15, packet loss on thein-band network 15, storage utilization, power utilization, and thelike. In some cases, these values may be read from registers associatedwith the corresponding electronic devices without interfacing with anoperating system of the corresponding rack-mounted computing device 13,in some cases via a BMC using the IPMI protocol. Or, in some cases,these values, and the other values read and actions taken, may beeffectuated without using a BMC of the rack-mounted computing devices.

FIGS. 7 and 8 depict techniques implemented in a system referred to as“Vapor Crate” for container, configuration, and file management forserver/workload orchestration/automation.

In some embodiments of a collection of racks, such as a Vapor chamberdescribed by the documents incorporated by reference, there are sixwedges (each being a rack), where each wedge contains a Vapor EdgeController (VECs) (or other type of rack control unit, like thosedescribed above, which may be dedicated computers coupled to a rackexecuting software to manage and monitor rack-mounted devices, likeservers, or may be executed by the rack-mounted computing devices), usedto host Vapor software such as Vapor CORE. The problem of how toconfigure and manage a large number of VECs (e.g., the rack controllersabove) while reducing the amount of human intervention is worthaddressing, as it may be difficult to manage all of the rack controlunits in a larger data center. In some cases, centralized management maypresent challenges. Relatively expensive, powerful computing equipmentmay be required for management tasks as the number of devices in a datacenter scales. Thus, at commercially relevant scales, computationalresources may impose constraints, in addition to or independent ofconstraints imposed by out-of-band management networks, particularlywhen relatively large machine images, OS updates, and container imagesare distributed to a relatively large number of computing devices. Thatsaid, some embodiments may have a centralized control architecture, asthe various other inventions described herein may also benefit suchsystems.

To mitigate some or all of these issues and others, in some embodiments,an autonomous management system called “Vapor Crate” (or Crate) isprovided. Vapor Crate may carry out some or all of the following tasks:

-   -   Service discovery, file and configuration synchronization (e.g.,        with a system referred to as “Forklift”)    -   Physical/logical mapping of management components based on role        (e.g., with a system referred to as “Manifest”)    -   Device (VEC) bootstrap (Forklift/bootstrap)    -   Configuration management (Manifest)    -   File management (Manifest)    -   Container management (e.g., with a system referred to as        “Dockworker”)    -   OS update management (e.g., with a system referred to as        “Hoist”)    -   UI Management (e.g., with Control Panel)

Crate may be implemented as a set of microservices, distributed acrossthe rack controllers or VECs in a data center. The architectureparallels best practices in the data center industry surroundingfault-expectancy, redundancy, replication, security, configurationmanagement, and decentralization. (Though embodiments are not limited tosystems that implement best practices, which is not to imply that anyother feature is limiting in all cases.) A feature of someimplementations of Crate is to remain fully available to survivingequipment in the event of a large-scale system failure (e.g. poweroutage in part of a data center in which a device previously having aleadership role in Crate is taken offline). Another feature of someimplementations is the ability to contain network traffic to a localbranch of the data center management network, as the transfer of datainvolved with such an endeavor can be non-trivial. Finally, a feature ofsome implementations is a self-managing system that lowered operationalcost by reducing or eliminating the need for operator intervention inmanaging hardware-management related software in a data center.

Vapor Crate, in some cases, includes service discovery and the abilityto synchronize files and configuration. These capabilities may beprovided by “Forklift”, a service that is included with rack controllersor VECs (e.g., as part of the program code) that discovers or isconfigured with the optimal (e.g., a local or global optimum) “leader”,which serves as the “master” for a given chamber (or other collection orracks). In some embodiments, the “leader” runs a redundant copy of allof the services listed above, typically within the scope of a singleVapor chamber or group of racks—the leader's services are synchronizedto a “primary” rack controller or VEC, designated by consensus in thedata center by the population of leaders. Updates may be made throughthe primary rack controller or VEC, and may be replicated to the leadersin the management unit. In case of failure of the ‘primary’, an electionmay be held by the consensus layer to choose a new primary, and theresults of the election may be replicated out to all leaders.

In some cases, Forklift discovers the existing services (including inbootstrap scenarios where a rack controller or VEC is the first to bebrought online in a data center), and discovers its own service profile,which specifies the services the rack controller or VEC is to run (forexample, to serve as a leader, or as an instance running Vapor CORE).The Crate API may be used by Forklift to communicate with Manifest toretrieve file and configuration information, and the appropriatecontainers (services) are retrieved from Dockworker, and are spun upusing docker-compose or similar orchestration tool. When a container isstarted, in some embodiments, the Crate API may also be used within thecontainer to retrieve from Manifest files or configuration informationneeded that is specialized to the VEC itself, allowing for a singleimage to be used, but configured to the needs of each individual rackcontroller or VEC where appropriate.

In some embodiments, OS updates may be provided by Hoist, a repreproDebian™ repository that may also contain specific package updates (e.g.to Forklift) as well. Hoist may provide a secure Debian™ repository forsoftware, as many data center management networks (e.g., out-of-bandnetworks) do not have outside network access. Additionally, Hoist mayallow for auditing and curation of package updates to suit user needs.In some embodiments, Dockworker is included for a similar reason—accessto Docker Hub™ is typically not possible for similar reasons in someimplementations, and Dockworker therefore may fill that void, and allowsfor curation and auditing of packages. That said, other embodiments mayhave out-of-band management networks with Internet access.

Gatekeeper may be used to provide authentication services used to secureCrate, and may also be used as the authentication service for Vapor COREor other products to provide fine-grained security from a single securelocation.

Manifest may use MongoDB™ as the data store and MongoDB's GridFS forschematized file storage. In some cases, MongoDB also includes aconsensus-based replication back-end that Crate piggybacks for its ownconsensus purposes—providing dual-purpose consensus protocol andelections, as well as notification of election results.

The Crate API, in some embodiments, includes a lightweight objectmapping that schematizes and validates object data exchanged between theAPI endpoint and MongoDB™. The API itself is may be implemented as aPython™ library that uses the object mapping to allow for ease of use byAPI consumers by providing a set of standard Python objects that may beexchanged between the API client and the endpoint. The API endpoint maybe a RESTful API backed by Nginx™ and uWSGI, with Flask as themicrodevelopment framework. Data may be exchanged in JSON format, andvalidated prior to interacting with the Manifest data store.

Some variations include a hosted management component to Crate, which isa service used to remotely manage Crate and Vapor services remotely,without the need for any customer intervention whatever. Othervariations include interaction with OpenSwitch™ or other NetworkOperating Systems (NOSes), where Crate is used on a switch or as part ofa NOS to perform management capabilities.

The form factor on which Crate runs may vary. In some embodiments, Cratemay be implemented for rack controller or VEC management, or it may beapplied to broader devops or automated systems management tasks.

Thus, some embodiments may implement control and updates at therack-level, in a distributed, concurrent fashion to facilitaterelatively large-scale operations. In some cases, activities specific toa rack can be handled locally at the rack level. To facilitate fan-out,some embodiments may distribute commands (which may include data bywhich the commands are implemented) through a hierarchical treestructure network graph, which in some cases may be established in parton an ad hoc, peer-to-peer, distributed basis. For instance, therack-level may be at a lower level than a Vapor chamber, and someembodiments may distribute one request per chamber, and then thatrequest may be replicated among the racks in that chamber. Examples mayinclude instructions for file and configuration management (e.g.,profiles), which may dictate how containers behave in each rack controlunit. Embodiments may push out something like a service profile thatsays what each controller should be running, e.g., via REST-basedexchange. To this end, for example, embodiments may send that file viaan API to an endpoint, which may be an arbitrarily chosen controller(e.g., with a consensus algorithm). The designated rack control unit maythen internally route that request to the known primary for thereplicated database. The data may then be sent to the primary, whichthen replicates it out to the replicas, e.g., one rack control unit perchamber. Often updates entail applying the same thing to every chamberand every rack, or in some cases updates may designate the set ofconfiguration and file data that is relevant to a particular class ofmachines or servers or racks. The determination to apply the receiveddata may be made at replica or at the primary level.

An example of a profile change is a change in a setting in aconfiguration for a container. To effect the change, some embodimentsmay send instructions to a replica to change the setting and thatsetting may be committed to the database. In some embodiments, otherrack control units may periodically check the designated master forupdates, e.g., with a pull operation every minute, making an API requestto the master requesting needed files. Some embodiments may have onemaster per chamber, and in some of these examples, anything pushed outto the primary gets pushed out to the masters/replicas. In someembodiments, if the primary fails, a new primary may be elected byconsensus among the devices.

When initializing a rack or a data center, files may be distributed in asimilar fashion to updates, with an arbitrarily chosen rack control unitacting as a seed. Upon boot, an initial master controller client thatruns on rack control units may periodically query for updates. A laptopor other computing device may be connected and initially be set to bethe provisioning unit via the endpoint running on that particularmachine, and other rack control unit may thereby obtain the files andsettings from the provisioning unit acting as a master. Then, someembodiments may change the settings of the chosen rack control unit toact as a master and seed distribution to other devices.

In some embodiments, a hierarchy of rack control units may be maintainedto limit the number of participants in a distributed database. Forinstance, some may be designated management units, which may thenreplicate to devices lower in the hierarchy.

In other embodiments, other techniques may be used for configuring rackcontrol units in a data center. For instance, some embodiments may usepeer-to-peer file sharing protocols, like BitTorrent. In someembodiments, device discovery and data routing may be achieved with adistributed hash table algorithm executing on the participating rackcontrol units (or other computers executing a rack controller). Suchtechniques, and those described above, are expected to make distributedcomputing systems run better than centralized management architectures,particularly as the number of nodes in a network scales and the amountof data to be distributed to each node expands. (This should not betaken as a disclaimer, though, of centralized architectures.) Thesetechniques are also applicable to query routing and distributedprocessing. For instance, the commands may take the form of queries orMapReduce functions.

As noted above, in some embodiments, the rack controllers maycommunicate with one another. In some embodiments, the rack controllersmay be updated, configured, monitored, queried, and otherwise accessedvia a peer-to-peer data center management system 70. The illustratedsystem 70 has topology shown in FIG. 7, indicating the way in whichinformation (such as commands, peer-to-peer networking overhead, andquery responses) flows through the management system 70 to manage therack controllers. In some cases, the topology represents connections atthe application layer, which may be built over the network layertopology described above with reference to FIGS. 1-4. As discussedabove, in some cases, the rack controllers are executed by dedicatedcomputing devices associated with racks, or in some cases byrack-mounted computing devices to execute in band applications. In someembodiments, the illustrated topology may be formed by the rackcontrollers, using a peer-to-peer consensus protocol described below. Insome embodiments, the topology may be a structured topology, such as atree topology like that shown in FIG. 7, or in other embodiments, thetopology may be an unstructured topology, e.g., in other forms of meshtopologies.

In some embodiments, the illustrated system may be relatively robust tofailure by one member of the system, for instance, by one of the rackcontrollers. In some embodiments, for certain operations, remaining rackcontrollers may detect the failure of a given rack controller andcontinue operation, designating other rack controllers fill a rolepreviously performed by a failed rack controller if that rack controllerhad a role significant to other parts of the system 70. In some cases,this may be accomplished with various consensus algorithms executed in adistributed fashion as described below with reference to FIG. 8, such asa leader-based consensus algorithm or a consensus algorithm that doesnot rely on a leader. Examples include the Raft consensus algorithmdescribed in Ongaro, Diego; Ousterhout, John (2013). “In Search of anUnderstandable Consensus Algorithm” (the contents of which are herebyincorporated by reference), and the Paxos consensus algorithm describedin Lamport, Leslie (May 1998). “The Part-Time Parliament” (PDF). ACMTransactions on Computer Systems 16, 2 (May 1998), 133-169 (the contentsof which are hereby incorporated by reference), among others. Incontrast, systems with rigid, predefined, unchangeable roles may berelatively sensitive to failure by any one computing device, as oftenthose systems require human intervention to replace that one computingdevice or otherwise reconfigure the system. In contrast, someembodiments may be fault tolerant and resilient to failures by computingdevices, applications therein, and network. That said, embodiments arenot limited to systems that afford these benefits, as there are variousindependently useful techniques described herein, some of which are notbased on consensus algorithms.

In the illustrated example, the rack controllers are arranged in ahierarchical tree in the topology of the management system 70. In FIG.7, the differing modifiers of “primary” and “lead” should not be takento indicate that, at least in some embodiments, the devices have adifferent architecture. Rather, in some embodiments, each of the devicesillustrated in FIG. 7, in some embodiments, may be an (e.g., identical)instance of a peer rack controller, each controlling a rack in thefashion described above. The lead and primary controllers may be simplydesignated rack controllers that perform additional tasks based on theirrole. The topology may be determined by the rack controllers themselves,dynamically, by executing the routines described below with reference toFIG. 8, in some cases, without a human assigning the roles andarrangement shown in FIG. 7, and with the topology self-evolving to healfrom the failure of devices. In this example, there are three levels tothe topology. At the highest level is a primary rack controller 72. At anext lower level, adjacent the primary rack controller, and therefore indirect communication with the primary rack 72 are lead rack controller74. Three rack controllers 74 are illustrated, but embodiments areconsistent with substantially more, for instance on the order of morethan 50 or more than 500. At the next level of the hierarchy, there area plurality of rack controller 76. Each lead rack controller 74 maycommunicate directly with a plurality of rack controllers 76, in somecases with those rack controllers 76 communicating exclusively with therack controller 74 through the management system 70 or purposes ofmanagement performed by the system 70. In some embodiments, each of therack controllers 76 may control a plurality of rack-mounted computingdevices 78 in the fashion described above. In some embodiments, theillustrated management systems 70 may be implemented in one or more ofthe above-described out-of-band networks. In some embodiments,management system may pass through the illustrated spanning tree, withreplication chaining, thereby distributing communication load across thenetwork and mitigating bottlenecks communication by which rack-mountedcomputing devices, racks, or rack controllers are controlled.

Control may take a variety of different forms. In some embodiments, acommand may be sent by the primary rack controller to update anoperating system of the rack controller or a rack-mounted computingdevice. In some embodiments, command may include an image of anoperating system, in some cases, an image of an operating system, anapplication executed within the operating system, dependencies of thatapplication may be included in the image. In another example, acontainer or microkernel may be configured or provisioned, for instancewith a corresponding disk image stored in, and distributed through, thetopology. In some cases, the command may be sent in sequence ofmessages, some including content by which the command is actuated andother messages including instructions to apply that content.

Other embodiments may include more or fewer levels to the hierarchyillustrated. For example, some embodiments may omit the primary rackcontroller 72, and commands may be distributed via chains spanning treesof the rack controllers 74 to the rack controller 76. Or someembodiments may include additional levels of hierarchy, for instancewith a plurality of primary rack controllers that are adjacent a higherlevel “super-primary” rack controller.

In some embodiments, updates, settings, and other management contentapplied to rack controllers or rack-mounted computing devices, likeoperating systems, applications, microkernel, containers, configurationfiles, and the like they be stored in a distributed repository, such asa distributed file system, or a distributed document database. In somecases, a distributed repository may have a topology that mirrors that ofthe illustrated management system 70. For example, some embodiments mayimplement the MongoDB™ document database, in some cases with theillustrated topology within the database and content be replicatedacross multiple instances illustrated containers, thereby providingredundancy, fault tolerance, data storage, as well as managementcapabilities. Other examples may implement a clustered file system, suchas the InterPlanetary File System as a distributed file system. In someembodiments, the same consensus algorithm by which the management systemdetermines, may be used to determine roles and authoritative copies ofdata in the distributed file system. In some cases, like in leaderlesssystems, roles may correspond to addresses within the topology ofmanagement content.

In some embodiments, the illustrated roles of the different rackcontrollers shown in FIG. 7 implement a distributed consensus protocolexecuted by the rack controllers. In some embodiments, the rackcontrollers may monitor the out-of-band network for a heartbeat signal,for instance in every few seconds, like every two seconds, sent by aleader among a group of rack controllers. Some embodiments may determinethat that heartbeat signal has not been received within a thresholdduration of time and in response initiates an election for a new leader.In some embodiments, each group of rack controllers, for instance, aplurality of 2 to 50, may have one designated leader for the groupthrough which commands are distributed to the group, and through whichinformation about the group is returned up through the illustrated treeof FIG. 7.

Upon determining that no leader heartbeat was received in time, andaction is warranted, a given rack controller making this determinationmay send a message to other rack controllers in the group indicatingthat the given rack controller requests their vote in an election. Insome embodiments, each rack controller may receive this message and todetermine whether to vote for that given rack controller in response.This determination may be based on a variety of differentconsiderations. For instance, each receiving rack controller maydetermine whether the group already has a leader and, in response, senda no vote (or decline to respond). In some embodiments, each receivingrack controller may determine whether the rack controller previouslyvoted an election within less than a threshold duration of time, inwhich case the rack controller may vote no. In some embodiments, eachrack controller may determine whether the rack controller already votedin the current election, in which case the rack controller may vote no.To this end, in some embodiments, when a given rack controller requestsa vote, that rack controller may increment a count that serves as aunique identifier for an election attempt within the group, and otherrack controllers may use this identifier sent with the vote request todetermine whether they have already voted within a given election bylogging their responses in memory and accessing this log to determinewhether they already have a logged vote associated with the electionattempt identifier. In another example, the receiving rack controllermay determine whether the request is the first request received with thegiven election attempt and, in response, return with a yes vote to thefirst request received and a no vote to other requests. In anotherexample, the vote requests may include a value indicative of a versionof data stored in a distributed file system by the requesting rackcontroller, and receiving rack controllers may determine whether to votefor that rack controller based on whether they store a more up-to-dateversion or based on whether another rack controller has requested a votewith a more up-to-date version.

In some embodiments, each rack controller may send a heartbeat signalperiodically, like every two seconds, to every rack controller in therespective group, and every rack controller in the group may receivethese heartbeat signals and maintain a list of rack controller in thegroup. Based on this list, the rack controller requesting a vote mayreceive votes in its favor and determine whether more than a majority ofvotes in favor have been received by counting votes received andcomparing the count to a threshold that is half the number of uniqueheartbeat signals received from members of the group. Upon receiving amajority of votes, and determining this to be the case, a given rackcontroller may determine that it has taken the role of a leader,communicate this to the group, and other rack controllers in the groupmay look to that rack controller as filling the role of leader.

Once leaders for each group are determined, in some cases, those leadersmay determine the primary rack controller with a similar technique, withthe leaders serving as the group in electing a member of the group tooperate as a primary rack controller.

In some embodiments, the time thresholds for determining whether a givenrack controller has failed may be adjusted according to a random value.Randomizing the threshold is expected to reduce the likelihood thatdifferent rack controllers call for elections concurrently with thegroup, thereby reducing the likelihood of tie elections delayed electionresults causing an election to be re-run.

At various times, various rack controllers filling various roles mayfail. Failure does not require that the computing device ceaseoperation, merely that the rack controller be perceived by other rackcontrollers to not perform at least part of the function correspondingto the role held by the rack controller. Examples include failure tosend a heartbeat signal, or failure to send a command or otherinformation through the topology 70 shown in FIG. 7 within a (e.g.,randomized, like pseudorandomized) threshold duration of time. In somecases, durations of time since the last signal was received may serve asa health score for each rack controller, and these health scores may bepropagated through the management system 70 according to the illustratedtopology, with a given rack controller reporting health scores for thosebelow it, and advancing those health scores upward, while distributinghealth scores for those upward to those below. This is expected to scalebetter relative to systems that implement a fully connected graph,though embodiments are also consistent with this approach.

FIG. 8 shows an example of a process 80 by which roles may be determinedand management may be effectuated within a data center managementsystem, such as that described above with reference to FIG. 7. In someembodiments, the process 80 includes determining a leader rackcontroller among a group a rack controllers, as indicated by block 82.In some cases, this operation may be performed when initializing a datacenter or in response to determining that a given previous leader rackcontroller is not responding. In some embodiments, determining a leadermay include determining a leader through the techniques described abovewith a distributed consensus protocol, with a plurality of rackcontrollers with a group communicating with one another in order toselect a leader (or primary) and arriving at a consensus regarding theselection.

Next, some embodiments may determine whether threshold duration haselapsed to receive a periodic signal (or other signal) from the leader,as indicated by block 84. In some cases, this may be receiving aheartbeat signal, or in some cases this may include a poor request, suchas a request for a response indicating the help of the leader. In somecases, block 82 may be done in a distributed fashion by the group, whileblock 84 may be performed by each member of the group. Similarly, eachmember of the group may determine in response to the time elapsing inblock 84 whether the leader is still operative, as indicated by block86. As noted above, an inoperative leader may still be functioning, butnot filling a portion of the role in the system, for instance in theevent of a network failure. If the leader is not operative, someembodiments may determine a new leader rack controller and return toblock 82, using the techniques described above.

If the leader is operative, some embodiments may determine whether thereis a new command from the leader, as indicated by block 88. In somecases, the command may be a series of messages, such as a messageinstructing rack mounting computing device to retrieve informationstored in a distributed file system, like an application update,descriptions of changing configurations, a container image, a diskimage, and the like, and apply that management content to a respectiverack controller with the command. In another example, the command may bea query to downstream rack controllers or a query to be translated andsent to downstream rack-mounted computing devices, for instance, withthe techniques described above.

Upon determining that there are no commands, some embodiments may returnto before block 84 and continue to wait for when for a periodic checkthat the leader is operative. In some cases, messages may be receivedbetween periodic heartbeats, for instance, with commands.

Upon determining that there is a new command, some embodiments maydistribute the commands to the rack controllers under the respectiveleader. In some embodiments, these operations 82 through 90 may beexecuted concurrently, asynchronously, by a plurality of differentgroups within the data center, in some cases, with different groupsselecting the leaders at different times.

In another example of a concurrent operation in some embodiments, upondetermining a leader for the rack controller among a group rackcontrollers, each rack controller may determine whether it is itself aleader, as indicated by block 92. This concurrent branch may end whenthe answer is no. Those rack controllers that determine that they havebeen elected the leader, may proceed to block 94, in which the leaderrack controllers may each determine whether there is a primary rackcontroller that is operative, as indicated by block 94. Thisdetermination may be similar to that of block 86 described above, withthe group of leaders serving as the relevant group. Upon determiningthat the leader is not operative, some embodiments may determine aprimary rack controller among the leader rack controllers, as indicatedby block 96. This operation may include executing one or more of theabove-described consensus protocols on the various leader rackcontrollers to elect a primary rack controller. Next, some embodimentsmay determine whether the time has arrived for a periodic check, asindicated by block 98. If the answer is no, some embodiments maycontinue waiting, or if the answer is yes, some embodiments may returnto block 94 and determine whether the primary rack controllers stilloperative. If the primary rack controller is determined to be operative,some embodiments may determine whether there is new command from theprimary rack, as indicated by block 100. Again, this operation mayinclude the operations described above with respect to block 88, exceptfrom the perspective of a leader. The operations of blocks 98, 94, and100 may be performed by each leader rack controller concurrently andasynchronously, and the operation of block 96 may be performedcollectively by the leader rack controllers. Upon determining that thereis no new command, some embodiments may return to block 98 and continuewaiting for a periodic check or new command.

In some cases, new commands may be pushed, without waiting to make adetermination whether a new command is available. Upon determining thata new command is available, some embodiments may distribute the commandto the leader rack controllers, as indicated by block 102. Thisoperation may include the operations described above with reference toblock 90, except from the perspective of leader rack controller. Thedistribution of block 102 may cause a positive response in thedetermination of block 88 above. Thus, new commands may be fanned outthroughout a topology of rack controllers without forming a bottleneckat any one rack controller, and the distribution may be accomplished ina way that is relatively fault-tolerant to the failure of any one rackcontroller of the data center management system 70. In some embodiments,the content by which the commands are implemented, which may includerelatively large files including operating systems, containers,applications, dependencies, and configuration settings, may bedistributed in the same or a similar fashion, thereby also distributingthe relatively bandwidth heavy load throughout the data center andavoiding bottlenecks, while also remaining resilient to failures. Again,it should be noted that several inventions are described, and thoseinventions may be viewed independently, so these benefits may not beafforded by all embodiments consistent with the present description.

As discussed above, often motherboards have hardware monitoring andprocessor diagnostics onboard for use by the local operating system.Often, the operating system is locked down tightly for security reasonswhich limits the availability of this data for remote collection, e.g.,for monitoring the operation of a data center via an out-of-band controlnetwork.

Some embodiments include a specialized service processor for monitoringand controlling a host computer (e.g., a server in a rack) that is moresecure than traditional baseboard management controllers. Thespecialized service processor may be isolated from the host computerexcept by a relatively low bandwidth connection that permits monitoringand control even when the host computer is turned off In someembodiments, the specialized service processor is responsive to APIcommands over an out-of-band network. In some cases, the serviceprocessor's network interface to the out-of-band network is alsoisolated from the host computer other than via the low-bandwidthconnection. The low bandwidth connection is expected to reduce theattack surface of the host computer (relative to many baseboardmanagement controllers having a high-bandwidth Ethernet connection) andimpede large transfers as might happen in a data breach or when anattacker attempts to download and install large executable files used inan attack.

A variety of interfaces are contemplated for the low-bandwidthconnection. Low-bandwidth connections (e.g., a low-bandwidth bus) have 4or fewer data lines clocked at less than 10 Mhz with two or fewer bitstransferred per line per clock cycle, e.g., in some cases one and onlyone data line clocked at less than 1 Mhz. In some embodiments, thelow-bandwidth connection is via a System Management Bus (SMBus), such asSMBus version 2 or version 3, as defined in the correspondingspecifications available from the System Management Interface Forum(SMIF), Inc., the contents of which are hereby incorporated byreference. In some embodiments, the low-bandwidth connection is via aPower Management Bus (PMBus) connection, which is a type of an SMBusconnection. (This list of examples (and other lists herein) should notbe ready to imply that one list item is not a type of another listitem.) In some embodiments, the connection is via an IntelligentPlatform Management Bus (IPMB) connection, for example, as defined inthe IPMB Communications Protocol Specification v.1.0 available fromIntel Corp., the contents of which are hereby incorporated by reference.In some cases, a baseboard management controller on a host computer maybe connected via an IPMB connection to an external service processor andmay be controlled by the external service processor, thereby protectingthe baseboard management controller while permitting use of itsfunctionality as indicated in the IPMB specification.

In some embodiments, the low-bandwidth connection is via anInter-Integrated Circuit (I²C) connection, each of the precedinglow-bandwidth connections being examples of I²C connections, such as viaan multi-master, multi-slave, single-ended, serial computer bus thatuses only two bidirectional open-drain lines: a Serial Clock Line (SCL)and a Serial Data Line (SDA). Both lines may be pulled up withresistors. In some embodiments, each electronic device on the bus mayassume one of two roles: a master device that outputs a clock signal onthe SCL and initiations communication with slave devices on the SDAline; and slave devices that receive the clock signal and takeresponsive action when an address on the SDA indicates a communicationis addressed to the respective slave device. In some cases, the I²Cconnection may be defined by UM10204, I²C-bus specification and usermanual, Ref 6, available from NXP Semiconductors N.V., the contents ofwhich are hereby incorporated by reference.

In each of these examples of a low-bandwidth connection, the connectionmay implement the corresponding physical media, signaling protocols,medium access control protocols, addressing, and timing techniquesspecified, among other aspects defined in the standards.

In some embodiments, via such connections, embodiments may override thehost computer's systems designed to control electronic devices on orconnected to a host computer motherboard. For instance, some embodimentsmay coordinate operation of such devices across host computers, e.g.,over an entire rack. Examples include taking control of a fan or otheractive system cooler, e.g., a Peltier thermoelectric cooler, or pumpcoupled to a liquid cooling system or vapor compression system. Someembodiments may open a switch on the motherboard by which the hostcomputer controls the electronic device and supply a control signal thatreplaces that of the host computer. For instance, some embodiments maycontrol speed of an electric motor (e.g., driving a fan or pump) orother device with a pulse-width modulated signal from the serviceprocessor. In some cases, the frequency of the signal may remaingenerally constant during operation, while a duty cycle may be adjustedto increase or decrease operation of the electronic device, e.g., toincrease a fan or pump speed or amount of thermoelectric cooling. Someembodiments may adjust active cooling on one host computer in responseto temperatures, cooling fluid flow, vibrations, fire, smoke,particulates, or other properties measured on another host computer on arack, e.g., in response to detecting a reversal of airflow direction inthe event of a positive pressure event in an exhaust passage. Someembodiments may adjust active cooling in response to workload assignedor scheduled to be assigned to a computing device, e.g., increasingcooling in response to such a signal indicating an impending increase(e.g., an increase in queue length at a load balancer, a failure ofanother computer sharing a load from a load balancer, or based onhistorical usage patterns).

Some embodiments may convey both data and power via the low-bandwidthconnection, e.g., supplying 12 volt power to the host computer on thesame lines used to exchange commands and monitoring data.

The following is described with reference to an SMBus as thelow-bandwidth connection, but any of the other examples may be used.Some embodiments may provide external centralized access (e.g., by arack control unit, to a motherboard of a rack-mounted computing device,like a server) by extending certain low level interfaces (e.g., SMBus)for the motherboard monitoring/control features to a connector forexternal (out of band) access. In some cases, the low-level interface isnarrowly tailored to provide sufficient access for management of a hostdevice, without creating the security risks described above presented bytraditional BMC that are 1) on-board, 2) have an on-board dedicatednetwork interface, and 3) are much more deeply interconnected to thehost computing device.

In some embodiments, this connector may supply the interface signals toa microcontroller (like those described above) that processes power linecommunications, but many other options are contemplated. Centralized(e.g., at the rack level) access to the hardware monitoring features ona motherboard are expected to provide capabilities such as managingserver fan speeds (CPU, chassis, etc.), monitoring motherboardtemperature sensors, monitoring motherboard rail voltages, and trackingCPU information from a rack level (or higher) controller. Rack levelcontrol of localized server fan speeds may bypass the local server fanspeed algorithm, so that multiple server models may be caused to behavesimilarly. It may also provide a custom fan speed algorithm optimizedfor the particular rack as determined by a rack level controller. Racklevel monitoring of motherboard rail voltages may be used to predicthardware failures before they cause a complete system failure. Thisprediction capability may trigger a transfer of the server's workload toanother location, flag the server as possibly failing, and then shut thesystem down before it is at risk. A variety of techniques of remotecollection are contemplated, including over power line communication,RS232, I2C, SPI, Ethernet, WiFi, Bluetooth, ZigBee, etc.

A variety of techniques may be used by the microcontroller to discoverdevices on the motherboard. For instance, firmware in the microchip,upon boot, may scan for devices and maintain an inventory in memory,which may be relayed to a rack control unit. In some cases, themicrocontroller may abstract the process of identifying andcommunicating with these components away from higher-level components,like the rack control unit. To scan and identify parts, themicrocontroller may take a number of steps to identify the part, asparts often do not have an identifier stored in a standardized registeraddress (or in some cases, in any address). In some cases, someembodiments may iterate through a list of likely register addresses thatare known to store part numbers, and responsive values may be comparedto an expected format to determine if a part number has been found. Insome embodiments, the microcontroller may perform a brute force scan byiterating through an address space, e.g., an entire address space of anI²C bus until a part is detected and, then, probe selected registers ofdetected devices to determine whether the registers store a part numberor evince a capability or configuration by which a part may beidentified, for instance, by comparing responsive signals to knownprofiles, or part-register fingerprints, stored in memory of themicrocontroller, such as particular addresses being read only memory orstoring a manufacturer identifier.

In some embodiments, the above microcontroller may be implemented andused in a dual-computer assembly 120 shown in FIG. 9. The illustratedassembly 120 includes the microcontroller 122 coupled to a motherboard124. The microcontroller 122 may form part of a secondary computingdevice that monitors and controls a primary computing device on themotherboard 124. In some embodiments, the microcontroller 122 may beimplemented on the network and power adapter 30 described above and mayinclude the features of the microcontroller 38 described above. In someembodiments, the motherboard 124 may be a motherboard of therack-mounted computing device 13 described above. The microcontroller122 may connect to an out-of-band network 146 via an out-of-bandphysical media 144, such as the various powerline networks or Ethernetnetworks described above.

Some embodiments include one dedicated secondary computing device foreach primary computing device, in a one-to-one relationship; someembodiments may monitor and control a plurality of primary computingdevices with a single secondary computing device; or some embodimentsmonitor and control different aspects of a single primary computingdevice with a plurality of different secondary computing devices. Insome embodiments, both the primary and the secondary computing devicesexecute a distinct operating system, having a distinct address space, ondifferent system boards, with physically different memory and physicallydifferent processors.

In some embodiments, the microcontroller 122 is external to themotherboard 124. Thus, the microcontroller 122 may be removablyelectrically coupled to the motherboard 124, for instance, by meansother than soldering the microcontroller to conductive traces on themotherboard, like with a connector 126 described in greater detailbelow. In some cases, a system board on which the microcontroller 122 ismounted may be separate from the motherboard and may include a differentnumber of layers from the motherboard. In some cases, a system board forthe microcontroller is oriented horizontally above or below themotherboard 124, in some cases, at an angle relative to the motherboard124, for instance, perpendicularly, like when connector 126 is an edgeconnector, in some embodiments.

In some embodiments, the microcontroller 122 may be configured tomonitor and control the primary computing device on the motherboard 124independently of an operating system, UEFI, or boot state of the primarycomputing device. For instance, some embodiments may be configured totake inventory of components on the motherboard, read identifying valuesfrom memory of those components, write values to registers of thosecomponents to configure the components, and power cycle the primarycomputing device, in some cases without directly interfacing with anoperating system of the primary computing device. Some embodiments mayperform these operations when the primary computing device is turned offor when the primary computing device is turned on.

Some embodiments of the microcontroller 122 may be configured to monitorand control the primary computing device on the motherboard 124independently of, and in some cases in the absence of, a BMC on themotherboard 124. Some embodiments may be configured to monitor andcontrol the primary computing device independently of, and in some casesin the absence of, using an IPMI interface of the primary computingdevice on the motherboard 124. Some embodiments may monitor and controlthe primary computing device on the motherboard 124 without using anetwork interface on the motherboard 124 to receive monitoring orcontrolling commands or to send responses to those commands to othercomputing devices, such as a data center administrator computing device25 like that described above or in a rack control unit 18 like thosedescribed above.

Some embodiments of the microcontroller 122 may be configured to monitorand control the primary computing device on the motherboard 124 via, forinstance solely via, a relatively low-pin-count bus connecting themicrocontroller 122 to the motherboard 124. Examples include a systemmanagement bus SMBus, and I²C, and LPC (each defined by a correspondingset of standards). In some embodiments, a point-to-point bus 132, forinstance implemented with a cable or conductive traces in a printedcircuit board, connects microcontroller 122 to such a low-pin-count bus130 on the motherboard 124, e.g. SMBus or one of the other examplesdescribed. In some cases, the bus 130 is a multipoint bus in which aplurality of electronic devices 128 and the microcontroller 122 (via thepoint-to-point bus 132) share the bus media and contend for access tothe bus media, for instance, with signals sent on the bus 130 reachingeach electronic device 128 and the microcontroller 122.

In some embodiments, the bus 130 has eight or fewer electricallyparallel conductors, for instance, five or fewer, or only two. In someembodiments, the bus 130 has a single conductor that carries a clocksignal to each of the devices 128 and 122 on the bus 130, and thesecomponents 128 and 122 may synchronize their communications on the bus130 according to the clock signal, e.g., a clock signal of less than 1MHz, less than 400 MHz, or less than 100 MHz. In some embodiments, thebus 130 has a single data conductor that carries a data signal in whichcommands, data, acknowledgment signals, error correction signals, andthe like are conveyed between components 128 and 122 communicating toone another on the bus 130. For instance, an eight-bit signal may besent over eight clock cycles on the single conductor. In someembodiments, the bus 130 also includes a pair of conductors, such as aground and 3 V or 5 V conductor, by which some devices 128 may powercertain operations.

In some embodiments, the bus 130 does not provide access to certainrelatively security-sensitive aspects of the primary computing device onthe motherboard 124. For instance, the bus 130, in some embodiments,does not support direct memory access to system memory of the primarycomputing device on the motherboard 124. Or some embodiments have a morefeature-rich bus 130 that supports DMA access. In some embodiments, thebus 130 does not support a bandwidth sufficiently high to download orinstall an operating system or complicated attack scripts, e.g.,supporting data rates of less than 1 Mb/second, like less than 0.5Mb/second, in contrast to many traditional BMCs implementations thatsupport data rates higher than 100 Mb/second.

In some embodiments, components coupled to the bus 130 may serve variousroles on the bus 130, in some cases with different roles at differenttimes. For example, some components may operate as a host of the bus130, some embodiments may operate as a master, and some may operate as aslave, for instance, receiving commands from a master device andresponding to those commands. In some cases, each component on the bus128 may have an address on the bus, such as a sixteen-or-fewer bitaddress, like a seven-bit address. In some embodiments, the devices 128may receive addresses preceding commands transmitted on the bus 130 anddetermine whether the received address matches an address of thecorresponding device before determining whether to process the command.

The electronic devices 128 may be any of a variety of different types ofcomponents on the motherboard 124. Examples include a central processingunit, system memory, a network interface, a graphical processing unit, amemory controller, a PCI bus controller, a fan, a power supply, atemperature sensor, a voltage sensor, a current sensor, a vibrationsensor, a moisture sensor, a Peltier cooler, and the like. In somecases, the electronic devices 128 may include an interface for the bus130 and memory storing an address of the corresponding device on the bus130. The memory may also store identifying and configuration values forthe corresponding electronic device 128. Examples of identifying valuesinclude serial numbers, manufacture identifiers, part numbers, firmwareidentifiers, firmware version identifiers, and the like. Examples ofconfiguration values include various values in registers that controlthe operation of, or output values from, the electronic device 128, suchas a register settings for a fan speed, a register setting for a clockspeed, a register settings for a buffer size, a register settings forthreshold values, a register settings for a currently read temperature,a register settings for a currently read voltage, a register storing acurrently read current, and the like. Some embodiments of the electronicdevices 128 may provide access to these various stored values via thebus 130, such as read and write access.

Thus, in some embodiments, the microcontroller 122 may monitor andcontrol the primary computing device on the motherboard 124 via arelatively low-pin, low-data-rate bus 130, like SMBus, by reading andwriting values in registers of the electronic devices 128 on the bus.Further, some embodiments may do so in a relatively secure fashion,without expanding an attack surface of the primary computing device onthe motherboard 124 with an onboard, relatively highly privileged,relatively highly interconnected, BMC having an on-board networkinterface on the motherboard 124.

In some embodiments, the connector 126 may be a soldered connection or aremovable connection, such as one with the same or fewer number ofconductors as are present on the bus 130. In some cases, the connector126 is an edge connector or a wire-to-board connector, like a Molex™connector. In some cases, the connector 126 is configured to mate with amatching connector on the motherboard 124, for instance, with aconnector 126 being a male connector that is complementary to a femaleconnector permanently attached to the motherboard 124. In someembodiments, the connector 126 is a removable connector, such that themicrocontroller 122 may be swapped out from the motherboard 124, e.g.,without desoldering the microcontroller 122 from the motherboard 124. Orin some embodiments, the microcontroller 122 is an on-boardmicrocontroller soldered to the motherboard 124, such as via an array ofpins coupled to the bus 130. In some embodiments, the bus 132 has thesame or fewer number of connections as the bus 130, for instance, withjust three or just five conductors. In some cases, the bus 132 isimplemented as a cable with a corresponding number of parallel wires.

In some embodiments, the microcontroller 122 includes an SMBus interface134, a processor 136, memory 138, and the out-of-band network interface140, each connected via a bus 142, such as a system bus of themicrocontroller 122. In some cases, the microcontroller 122 is anintegrated system-on-a-chip, or in some cases, the various componentsillustrated may be discrete components, for instance, coupled to oneanother via a printed circuit board. In some embodiments, theout-of-band network interface may interface with (or be) the powerlinemodem 36 described above or the various other types of out-of-bandnetwork interfaces described above. In some embodiments, the processor136 executes instructions stored in memory 138 and reads and writesvalues to memory 138 via a bus 142 that is separate from the conductivetraces on the motherboard 124 other than via the connector 126. Forinstance, the microcontroller 122, in some embodiments, has a separateaddress space from that of a primary computing device on the motherboard124.

In some embodiments, the memory 138 may include persistent memory, suchas flash memory, storing instructions that when executed by theprocessor 136 effectuate a process described below with reference toFIG. 10.

Some embodiments are configured to execute a process 150 of FIG. 10 tomonitor or control one or more of the electronic devices 128 describedabove, for instance, via the bus 132, the connector 126, and the bus130. Some embodiments may receive, with an off-board network interface,via an out-of-band network, a first command from a computing deviceconfigured to monitor or control a plurality of rack-mounted computingdevices, as indicated by block 152. In some cases, the first command isreceived from one of the rack-control units 18 described above, forinstance, via a direct current powerline network or other network. Insome cases, the first command may be received via a dedicated racknetwork having an address space limited to computing devices on therack, or in some cases, the first command may be received via a largernetwork.

The first command may be any of a variety of different types ofcommands, like the examples described above issued by the rack controlunit 18, for instance, responsive to commands sent to the rack controlunit 18 by other rack control units or an administrator computer device.For instance, the command may be a command to monitor a givenrack-mounted computing device coupled to the microcontroller 122 via theconnector 126.

Next, some embodiments may send a second command, based on the firstcommand, via the connector, to an electronic device coupled to SMBus andon the motherboard, as indicated by block 154. In some cases, thereceived command may be translated into a command recognizable by anelectronic device on the bus 130 described above. This may includereceiving a command in a format generic to a class of electronicdevices, like a command to read a temperature from a temperature sensor,and translating that command into a format suitable for a specificinstance of that class, like a particular manufacturer's temperaturesensor having a particular model number. Some embodiments may retrievefrom memory of the microcontroller an identifier of the electronicdevice and translate the command based on a stored record indicating acorresponding command recognized by the specific electronic device.

Translating the command may include formatting the command in accordancewith a protocol of the bus 130. For instance, some embodiments may senda value indicating that control of the bus is being taken over, followedby a seven-bit address (sent in sequence), followed by a single bitindicating a read or write operation, before receiving an acknowledgmentsignal (e.g., one bit in a designated clock cycle). In some cases, thismay be followed by a sequence of bits indicating a parameter of thecommand like an eight-bit data value, such as a register address of theelectronic device. In some cases, each of these bits may be sent insequence according to a clock cycle of the bus, down a single dataconnector, for instance, in accordance with the I²C protocol or theSMBus protocol (e.g., version 2 or 3), each of which are incorporated byreference.

Next, some embodiments may receive a response to the command via SMBusfrom the electronic device, as indicated by block 156. In some cases,the response may be a value read from a register or a response codeindicating that a command was executed successfully or a failure code.In some cases, receiving the response may include transmitting anacknowledgment bit after receiving the response.

Next, some embodiments may transmit data based on the response, with theoff-board network interface, via the out-of-band network, to thecomputing device configured to monitor or control a plurality ofrack-mounted computing devices, as indicated by block 158. Again, insome cases, this may include translating the received data from adevice-specific format to a different format used for a plurality ofdifferent instances of the class of devices. For example, a receivedvalue may indicate a voltage of a temperature sensor, and someembodiments may translate that voltage into a temperature based on alookup table (or parameters of a formula) stored in memory inassociation with an identifier of the electronic device. Or someembodiments may receive a response code to a command to adjust the fanspeed, and some embodiments may translate that response code into acanonical format based on a lookup table associated with the device.

Some embodiments may execute a variety of different types of monitoringand control. In some cases, monitoring includes taking inventory ofelectronic devices on the bus 130. Some embodiments may iterate throughan address space of the bus, for instance, sending commands to each of127 different addresses, and determining which addresses produce aresponse. Some embodiments may save that list of responsive addresses inmemory and then probe each responsive address to identify the electronicdevice. In some cases, this may include sending a command to read avalue in a register in a memory address space of the electronic device.In some cases, this may include scanning the memory address space for anidentifying value, such as a value matching a regular expressionconfigured to identify part numbers or manufacturers. Some embodimentsmay maintain in memory a list of addresses of registers of commonly usedparts known to contain identifiers, such as registers written during amanufacturing process with a part number. In some cases, this inventorymay be sent to a rack control unit, which may relay the inventory toanother computing device. Some embodiments may store in memory aregister signature of known electronic device part numbers, and someembodiments may read values from registers of the electronic devices onthe bus 130 and match responses to the signatures to identify thecorresponding electronic device, for instance, a type of device, amanufacturer of the device, or a part number.

Some embodiments may exercise various types of control via the bus 130,for instance, shutting down the primary computing device, booting theprimary computing device, or changing configurations of electronicdevices by writing to registers. In some cases, some embodiments mayexecute local (e.g., such that action is taken responsive to feedbackwithout subsequent direction from a remote computing device) controlroutines based on monitoring, such as five more concurrently executedroutines. For example, some embodiments may periodically read a valueindicative of a voltage or current of a trace on the motherboard,compare the value to a threshold, and responsive to the threshold beingexceeded, send a command to shut down the computing device. Someembodiments may also send a command via the out-of-band networkindicating that the work performed by the primary computing deviceshould be transferred elsewhere. Thus, some embodiments may shield therack control unit from the complexity of interfacing with the electronicdevices 128 via the bus 130, in some cases, with diverse sets ofelectronic devices 128 within a given rack. Further, some embodimentsmay do so in a relatively secure fashion, avoiding some of the problemswith BMCs in some conventional designs, though embodiments are alsoconsistent with use of a BMC in some implementations.

FIG. 11 is a diagram that illustrates an exemplary computing system 1000in accordance with embodiments of the present technique. In some cases,each rack of the above-described racks may house one or more of thesesystems 1000. Various portions of systems and methods described herein,may include or be executed on one or more computer systems similar tocomputing system 1000. Further, processes and modules described hereinmay be executed by one or more processing systems similar to that ofcomputing system 1000.

Computing system 1000 may include one or more processors (e.g.,processors 1010 a-1010 n) coupled to system memory 1020, an input/outputI/O device interface 1030, and a network interface 1040 via aninput/output (I/O) interface 1050. A processor may include a singleprocessor or a plurality of processors (e.g., distributed processors). Aprocessor may be any suitable processor capable of executing orotherwise performing instructions. A processor may include a centralprocessing unit (CPU) that carries out program instructions to performthe arithmetical, logical, and input/output operations of computingsystem 1000. A processor may execute code (e.g., processor firmware, aprotocol stack, a database management system, an operating system, or acombination thereof) that creates an execution environment for programinstructions. A processor may include a programmable processor. Aprocessor may include general or special purpose microprocessors. Aprocessor may receive instructions and data from a memory (e.g., systemmemory 1020). Computing system 1000 may be a uni-processor systemincluding one processor (e.g., processor 1010 a), or a multi-processorsystem including any number of suitable processors (e.g., 1010 a-1010n). Multiple processors may be employed to provide for parallel orsequential execution of one or more portions of the techniques describedherein. Processes, such as logic flows, described herein may beperformed by one or more programmable processors executing one or morecomputer programs to perform functions by operating on input data andgenerating corresponding output. Processes described herein may beperformed by, and apparatus can also be implemented as, special purposelogic circuitry, e.g., an FPGA (field programmable gate array) or anASIC (application specific integrated circuit). Computing system 1000may include a plurality of computing devices (e.g., distributed computersystems) to implement various processing functions.

I/O device interface 1030 may provide an interface for connection of oneor more I/O devices 1060 to computer system 1000. I/O devices mayinclude devices that receive input (e.g., from a user) or outputinformation (e.g., to a user). I/O devices 1060 may include, forexample, graphical user interface presented on displays (e.g., a cathoderay tube (CRT) or liquid crystal display (LCD) monitor), pointingdevices (e.g., a computer mouse or trackball), keyboards, keypads,touchpads, scanning devices, voice recognition devices, gesturerecognition devices, printers, audio speakers, microphones, cameras, orthe like. I/O devices 1060 may be connected to computer system 1000through a wired or wireless connection. I/O devices 1060 may beconnected to computer system 1000 from a remote location. I/O devices1060 located on remote computer system, for example, may be connected tocomputer system 1000 via a network and network interface 1040.

Network interface 1040 may include a network adapter that provides forconnection of computer system 1000 to a network. Network interface may1040 may facilitate data exchange between computer system 1000 and otherdevices connected to the network. Network interface 1040 may supportwired or wireless communication. The network may include an electroniccommunication network, such as the Internet, a local area network (LAN),a wide area network (WAN), a cellular communications network, or thelike.

System memory 1020 may be configured to store program instructions 1100or data 1110. Program instructions 1100 may be executable by a processor(e.g., one or more of processors 1010 a-1010 n) to implement one or moreembodiments of the present techniques. Instructions 1100 may includemodules of computer program instructions for implementing one or moretechniques described herein with regard to various processing modules.Program instructions may include a computer program (which in certainforms is known as a program, software, software application, script, orcode). A computer program may be written in a programming language,including compiled or interpreted languages, or declarative orprocedural languages. A computer program may include a unit suitable foruse in a computing environment, including as a stand-alone program, amodule, a component, or a subroutine. A computer program may or may notcorrespond to a file in a file system. A program may be stored in aportion of a file that holds other programs or data (e.g., one or morescripts stored in a markup language document), in a single filededicated to the program in question, or in multiple coordinated files(e.g., files that store one or more modules, sub programs, or portionsof code). A computer program may be deployed to be executed on one ormore computer processors located locally at one site or distributedacross multiple remote sites and interconnected by a communicationnetwork.

System memory 1020 may include a tangible program carrier having programinstructions stored thereon. A tangible program carrier may include anon-transitory computer readable storage medium. A non-transitorycomputer readable storage medium may include a machine readable storagedevice, a machine readable storage substrate, a memory device, or anycombination thereof. Non-transitory computer readable storage medium mayinclude non-volatile memory (e.g., flash memory, ROM, PROM, EPROM,EEPROM memory), volatile memory (e.g., random access memory (RAM),static random access memory (SRAM), synchronous dynamic RAM (SDRAM)),bulk storage memory (e.g., CD-ROM or DVD-ROM, hard-drives), or the like.System memory 1020 may include a non-transitory computer readablestorage medium that may have program instructions stored thereon thatare executable by a computer processor (e.g., one or more of processors1010 a-1010 n) to cause the subject matter and the functional operationsdescribed herein. A memory (e.g., system memory 1020) may include asingle memory device or a plurality of memory devices (e.g., distributedmemory devices).

I/O interface 1050 may be configured to coordinate I/O traffic betweenprocessors 1010 a-1010 n, system memory 1020, network interface 1040,I/O devices 1060, or other peripheral devices. I/O interface 1050 mayperform protocol, timing, or other data transformations to convert datasignals from one component (e.g., system memory 1020) into a formatsuitable for use by another component (e.g., processors 1010 a-1010 n).I/O interface 1050 may include support for devices attached throughvarious types of peripheral buses, such as a variant of the PeripheralComponent Interconnect (PCI) bus standard or the Universal Serial Bus(USB) standard.

Embodiments of the techniques described herein may be implemented usinga single instance of computer system 1000 or multiple computer systems1000 configured to host different portions or instances of embodiments.Multiple computer systems 1000 may provide for parallel or sequentialprocessing/execution of one or more portions of the techniques describedherein.

Those skilled in the art will appreciate that computer system 1000 ismerely illustrative and is not intended to limit the scope of thetechniques described herein. Computer system 1000 may include anycombination of devices or software that may perform or otherwise providefor the performance of the techniques described herein. For example,computer system 1000 may include or be a combination of acloud-computing system, a data center, a server rack, a server, avirtual server, a desktop computer, a laptop computer, a tabletcomputer, a server device, a client device, a mobile telephone, apersonal digital assistant (PDA), a mobile audio or video player, a gameconsole, a vehicle-mounted computer, or a Global Positioning System(GPS), or the like. Computer system 1000 may also be connected to otherdevices that are not illustrated, or may operate as a stand-alonesystem. In addition, the functionality provided by the illustratedcomponents may in some embodiments be combined in fewer components ordistributed in additional components. Similarly, in some embodiments,the functionality of some of the illustrated components may not beprovided or other additional functionality may be available.

Those skilled in the art will also appreciate that while various itemsare illustrated as being stored in memory or on storage while beingused, these items or portions of them may be transferred between memoryand other storage devices for purposes of memory management and dataintegrity. Alternatively, in other embodiments some or all of thesoftware components may execute in memory on another device andcommunicate with the illustrated computer system via inter-computercommunication. Some or all of the system components or data structuresmay also be stored (e.g., as instructions or structured data) on acomputer-accessible medium or a portable article to be read by anappropriate drive, various examples of which are described above. Insome embodiments, instructions stored on a computer-accessible mediumseparate from computer system 1000 may be transmitted to computer system1000 via transmission media or signals such as electrical,electromagnetic, or digital signals, conveyed via a communication mediumsuch as a network or a wireless link. Various embodiments may furtherinclude receiving, sending, or storing instructions or data implementedin accordance with the foregoing description upon a computer-accessiblemedium. Accordingly, the present invention may be practiced with othercomputer system configurations.

The reader should appreciate that the present application describesseveral inventions. Rather than separating those inventions intomultiple isolated patent applications, applicants have grouped theseinventions into a single document because their related subject matterlends itself to economies in the application process. But the distinctadvantages and aspects of such inventions should not be conflated. Insome cases, embodiments address all of the deficiencies noted herein,but it should be understood that the inventions are independentlyuseful, and some embodiments address only a subset of such problems oroffer other, unmentioned benefits that will be apparent to those ofskill in the art reviewing the present disclosure. Due to costconstraints, some inventions disclosed herein may not be presentlyclaimed and may be claimed in later filings, such as continuationapplications or by amending the present claims. Similarly, due to spaceconstraints, neither the Abstract nor the Summary of the Inventionsections of the present document should be taken as containing acomprehensive listing of all such inventions or all aspects of suchinventions.

It should be understood that the description and the drawings are notintended to limit the invention to the particular form disclosed, but tothe contrary, the intention is to cover all modifications, equivalents,and alternatives falling within the spirit and scope of the presentinvention as defined by the appended claims. Further modifications andalternative embodiments of various aspects of the invention will beapparent to those skilled in the art in view of this description.Accordingly, this description and the drawings are to be construed asillustrative only and are for the purpose of teaching those skilled inthe art the general manner of carrying out the invention. It is to beunderstood that the forms of the invention shown and described hereinare to be taken as examples of embodiments. Elements and materials maybe substituted for those illustrated and described herein, parts andprocesses may be reversed or omitted, and certain features of theinvention may be utilized independently, all as would be apparent to oneskilled in the art after having the benefit of this description of theinvention. Changes may be made in the elements described herein withoutdeparting from the spirit and scope of the invention as described in thefollowing claims. Headings used herein are for organizational purposesonly and are not meant to be used to limit the scope of the description.

As used throughout this application, the word “may” is used in apermissive sense (i.e., meaning having the potential to), rather thanthe mandatory sense (i.e., meaning must). The words “include”,“including”, and “includes” and the like mean including, but not limitedto. As used throughout this application, the singular forms “a,” “an,”and “the” include plural referents unless the content explicitlyindicates otherwise. Thus, for example, reference to “an element” or “aelement” includes a combination of two or more elements, notwithstandinguse of other terms and phrases for one or more elements, such as “one ormore.” The term “or” is, unless indicated otherwise, non-exclusive,i.e., encompassing both “and” and “or.” Terms describing conditionalrelationships, e.g., “in response to X, Y,” “upon X, Y,”, “if X, Y,”“when X, Y,” and the like, encompass causal relationships in which theantecedent is a necessary causal condition, the antecedent is asufficient causal condition, or the antecedent is a contributory causalcondition of the consequent, e.g., “state X occurs upon condition Yobtaining” is generic to “X occurs solely upon Y” and “X occurs upon Yand Z.” Such conditional relationships are not limited to consequencesthat instantly follow the antecedent obtaining, as some consequences maybe delayed, and in conditional statements, antecedents are connected totheir consequents, e.g., the antecedent is relevant to the likelihood ofthe consequent occurring. Statements in which a plurality of attributesor functions are mapped to a plurality of objects (e.g., one or moreprocessors performing steps A, B, C, and D) encompasses both all suchattributes or functions being mapped to all such objects and subsets ofthe attributes or functions being mapped to subsets of the attributes orfunctions (e.g., both all processors each performing steps A-D, and acase in which processor 1 performs step A, processor 2 performs step Band part of step C, and processor 3 performs part of step C and step D),unless otherwise indicated. Further, unless otherwise indicated,statements that one value or action is “based on” another condition orvalue encompass both instances in which the condition or value is thesole factor and instances in which the condition or value is one factoramong a plurality of factors. Unless specifically stated otherwise, asapparent from the discussion, it is appreciated that throughout thisspecification discussions utilizing terms such as “processing,”“computing,” “calculating,” “determining” or the like refer to actionsor processes of a specific apparatus, such as a special purpose computeror a similar special purpose electronic processing/computing device.

The present techniques will be better understood with reference to thefollowing enumerated embodiments:

1. A secondary computing device configured to monitor or control arack-mounted computing device independently of whether the rack-mountedcomputing device is operating or is turned off, the secondary computingdevice comprising: a low-bandwidth bus connector configured to connectto a low-bandwidth bus on a motherboard of a rack-mounted computingdevice; and an off-motherboard microcontroller electrically coupled tothe low-bandwidth bus connector, the microcontroller comprising one ormore processors and memory storing instructions that, when executed byat least some of the processors, effectuate operations comprising:receiving, with an off-motherboard network interface, via an out-of-bandnetwork, a first command from computing device configured to monitor orcontrol a plurality of rack-mounted computing devices; sending a secondcommand based on the first command via the connector to an electronicdevice coupled to the low-bandwidth bus on the motherboard; receiving aresponse to the second command via the low-bandwidth bus from theelectronic device; and transmitting data based on the response, with theoff-motherboard network interface, via the out-of-band network, to thecomputing device configured to monitor or control a plurality ofrack-mounted computing devices.2. The secondary computing device of embodiment 1, wherein: thelow-bandwidth bus is an System Management Bus (SMBus) connector that isa removable connector configured: to be held in place on themotherboard, at least in part, by a resilient member; and to connect tothe SMBus via electrical contact with five or fewer conductors, a firstconductor of the five or fewer conductors being a clock-signalconductor, a second conductor of the five or fewer conductors being adata conductor, the clock-signal conductor being configured to receive aclock-signal operating at less than 10 MHz.3. The secondary computing device of any one of embodiments 1-2,comprising: the off-motherboard network interface communicativelycoupled to the one or more processors.4. The secondary computing device of embodiment 3, wherein: theoff-motherboard network interface comprises an Ethernet networkinterface.5. The secondary computing device of embodiment 3, wherein: theoff-motherboard network interface comprises a powerline communicationmodem.6. The secondary computing device of embodiment 5, comprising: a bus-barconnector configured to couple to a bus bar extending past, andproviding direct current power to, a plurality of rack-mounted computingdevices; and a filter configured to separate a data signal from directcurrent power conducted by the bus bar.7. The secondary computing device of any one of embodiments 1-6, whereinthe operations comprise: adjusting a fan speed of a fan controlled viathe motherboard.8. The secondary computing device of any one of embodiments 1-7, whereinthe operations comprise: reading a value from a motherboard temperaturesensor indicative of a temperature of a component on the motherboard.9. The secondary computing device of any one of embodiments 1-8, whereinthe operations comprise: reading a value from a motherboard voltagesensor indicative of a voltage of a conductive trace of the motherboard.10. The secondary computing device of any one of embodiments 1-9,wherein the operations comprise: turning off the rack-mounted computingdevice; and turning on the rack-mounted computing device.11. The secondary computing device of any one of embodiments 1-10,wherein the operations comprise: scanning an address space of thelow-bandwidth bus; and compiling an inventory of responsive electronicdevices based on acknowledgement signals sent by electronic devices upona respective signal being sent to the respective electronic device'saddress on the low-bandwidth bus during the scanning.12. The secondary computing device of any one of embodiments 1-11,wherein the operations comprise: determining an identity of theelectronic device by probing a register address space of the electronicdevice to obtain an identifier.13. The secondary computing device of any one of embodiments 1-12,wherein: the second command is sent via only one electrically conductivepath between the off-board microcontroller and the low-bandwidth busconnector.14. The secondary computing device of any one of embodiments 1-13,wherein: the off-board microcontroller is configured to monitor andcontrol a plurality of electronic devices on the motherboard solely viathe low-bandwidth bus, without controlling or monitoring the pluralityof electronic devices via other busses on the motherboard.15. The secondary computing device of any one of embodiments 1-14,wherein: the microcontroller is configured to read a value from registerof the electronic device via the low-bandwidth bus when the rack-mountedcomputing device is turned off.16. The secondary computing device of any one of embodiments 1-15,wherein sending the second command comprises, on a given conductorcoupled to the low-bandwidth bus connector, in sequence: transmitting astart bit; transmitting seven bits in sequence encoding an address ofthe electronic device on the low-bandwidth bus; transmitting a valueindicating a write operation; receiving a first acknowledgement bit fromthe electronic device; transmitting eight bits in sequence encoding acommand code; receiving a second acknowledgement bit from the electronicdevice; transmitting eight bits in sequence encoding data sent to theelectronic device.17. The secondary computing device of any one of embodiments 1-16,comprising: means for taking inventory of electronic devices coupled tothe low-bandwidth bus; means for controlling a motherboard fan speed;means for communicating via the out-of-band network; means formonitoring or controlling the rack-mounted computing device withoutrelying on a baseboard management controller of the rack-mountedcomputing device.18. The secondary computing device of any one of embodiments 1-17,comprising: a rack configured to hold a plurality of secondary computingdevices, including a given secondary computing device including thelow-bandwidth bus connector and the microcontroller; a rack-specificnetwork configured to couple to each of the secondary computing devicesheld by the rack; and a rack-control unit configured to control andmonitor rack-mounted computing devices in the rack via the rack-specificnetwork and the plurality of secondary computing devices.19. The secondary computing device of any one of embodiments 1-18,comprising: a rack-mounted computing device coupled to the low-bandwidthbus connector.20. The secondary computing device of embodiment 19, wherein: therack-mounted computing device comprises memory storing instructions thatprovide a service via the Internet to a client computing device or aservice to other rack-mounted computing devices.21. The secondary computing device of claim 1, wherein: thelow-bandwidth bus is an Intelligent Platform Management Bus (IPMB).22. The secondary computing device of claim 1, wherein: thelow-bandwidth bus is a Power Management Bus (PMBus).23. A tangible, non-transitory, machine-readable medium storinginstructions that when executed by one or more processors effectuateoperations comprising: the operations of any one of embodiments 1-22.24. A method, comprising: the operations of any one of embodiments 1-22.

What is claimed is:
 1. A secondary computing device configured tomonitor or control a rack-mounted computing device independently ofwhether the rack-mounted computing device is operating or is turned off,the secondary computing device comprising: a low-bandwidth bus connectorconfigured to connect to a low-bandwidth bus on a motherboard of arack-mounted computing device; and an off-motherboard microcontrollerelectrically coupled to the low-bandwidth bus connector, themicrocontroller comprising one or more processors and memory storinginstructions that, when executed by at least some of the processors,effectuate operations comprising: receiving, with an off-motherboardnetwork interface, via an out-of-band network, a first command fromcomputing device configured to monitor or control a plurality ofrack-mounted computing devices; sending a second command based on thefirst command via the connector to an electronic device coupled to thelow-bandwidth bus on the motherboard; receiving a response to the secondcommand via the low-bandwidth bus from the electronic device; andtransmitting data based on the response, with the off-motherboardnetwork interface, via the out-of-band network, to the computing deviceconfigured to monitor or control a plurality of rack-mounted computingdevices.
 2. The secondary computing device of claim 1, wherein: thelow-bandwidth bus is a System Management Bus (SMBus) connector coupledto an SMBus on the motherboard and is a removable connector configured:to be held in place on the motherboard, at least in part, by a resilientmember; and to connect to the SMBus via electrical contact with five orfewer conductors, a first conductor of the five or fewer conductorsbeing a clock-signal conductor, a second conductor of the five or fewerconductors being a data conductor, the clock-signal conductor beingconfigured to receive a clock-signal operating at less than 10 MHz. 3.The secondary computing device of claim 1, comprising: theoff-motherboard network interface communicatively coupled to the one ormore processors.
 4. The secondary computing device of claim 3, wherein:the off-motherboard network interface comprises an Ethernet networkinterface.
 5. The secondary computing device of claim 3, wherein: theoff-motherboard network interface comprises a powerline communicationmodem.
 6. The secondary computing device of claim 5, comprising: abus-bar connector configured to couple to a bus bar extending past, andproviding direct current power to, a plurality of rack-mounted computingdevices; and a filter configured to separate a data signal from directcurrent power conducted by the bus bar.
 7. The secondary computingdevice of claim 1, wherein the operations comprise: adjusting a fanspeed of a fan controlled via the motherboard by disengaging control ofthe fan by the rack-mounted computing device and sending a pulse-widthmodulated signal having a duty cycle corresponding to a target fanspeed.
 8. The secondary computing device of claim 1, wherein theoperations comprise: reading a value from a motherboard temperaturesensor indicative of a temperature of a component on the motherboard. 9.The secondary computing device of claim 1, wherein the operationscomprise: reading a value from a motherboard voltage sensor indicativeof a voltage of a conductive trace of the motherboard.
 10. The secondarycomputing device of claim 1, wherein the operations comprise: turningoff the rack-mounted computing device; and turning on the rack-mountedcomputing device.
 11. The secondary computing device of claim 1, whereinthe operations comprise: scanning an address space of the low-bandwidthbus; and compiling an inventory of responsive electronic devices basedon acknowledgement signals sent by electronic devices upon a respectivesignal being sent to the respective electronic device's address on thelow-bandwidth bus during the scanning.
 12. The secondary computingdevice of claim 1, wherein the operations comprise: determining anidentity of the electronic device by probing a register address space ofthe electronic device to obtain an identifier.
 13. The secondarycomputing device of claim 1, wherein: the second command is sent viaonly one electrically conductive path between the off-boardmicrocontroller and the low-bandwidth bus connector.
 14. The secondarycomputing device of claim 1, wherein: the off-board microcontroller isconfigured to monitor and control a plurality of electronic devices onthe motherboard solely via the low-bandwidth bus, without controlling ormonitoring the plurality of electronic devices via other busses on themotherboard.
 15. The secondary computing device of claim 1, wherein: themicrocontroller is configured to read a value from register of theelectronic device via the low-bandwidth bus when the rack-mountedcomputing device is turned off.
 16. The secondary computing device ofclaim 1, wherein sending the second command comprises, on a givenconductor coupled to the low-bandwidth bus connector, in sequence:transmitting a start bit; transmitting seven bits in sequence encodingan address of the electronic device on the low-bandwidth bus;transmitting a value indicating a write operation; receiving a firstacknowledgement bit from the electronic device; transmitting eight bitsin sequence encoding a command code; receiving a second acknowledgementbit from the electronic device; transmitting eight bits in sequenceencoding data sent to the electronic device.
 17. The secondary computingdevice of claim 1, comprising: means for taking inventory of electronicdevices coupled to the low-bandwidth bus; means for controlling amotherboard fan speed; means for communicating via the out-of-bandnetwork; means for monitoring or controlling the rack-mounted computingdevice without relying on a baseboard management controller of therack-mounted computing device.
 18. The secondary computing device ofclaim 1, comprising: a rack configured to hold a plurality of secondarycomputing devices, including a given secondary computing deviceincluding the low-bandwidth bus connector and the microcontroller; arack-specific network configured to couple to each of the secondarycomputing devices held by the rack; and a rack-control unit configuredto control and monitor rack-mounted computing devices in the rack viathe rack-specific network and the plurality of secondary computingdevices.
 19. The secondary computing device of claim 1, comprising: arack-mounted computing device coupled to the low-bandwidth busconnector.
 20. The secondary computing device of claim 19, wherein: therack-mounted computing device comprises memory storing instructions thatprovide a service via the Internet to a client computing device or aservice to other rack-mounted computing devices.
 21. The secondarycomputing device of claim 1, wherein: the low-bandwidth bus is anIntelligent Platform Management Bus (IPMB).
 22. The secondary computingdevice of claim 1, wherein: the low-bandwidth bus is a Power ManagementBus (PMBus).